30 Jan, 2015
40 commits
-
commit 3e14dcf7cb80b34a1f38b55bc96f02d23fdaaaaf upstream.
Commit 5d26a105b5a7 ("crypto: prefix module autoloading with "crypto-"")
changed the automatic module loading when requesting crypto algorithms
to prefix all module requests with "crypto-". This requires all crypto
modules to have a crypto specific module alias even if their file name
would otherwise match the requested crypto algorithm.Even though commit 5d26a105b5a7 added those aliases for a vast amount of
modules, it was missing a few. Add the required MODULE_ALIAS_CRYPTO
annotations to those files to make them get loaded automatically, again.
This fixes, e.g., requesting 'ecb(blowfish-generic)', which used to work
with kernels v3.18 and below.Also change MODULE_ALIAS() lines to MODULE_ALIAS_CRYPTO(). The former
won't work for crypto modules any more.Fixes: 5d26a105b5a7 ("crypto: prefix module autoloading with "crypto-"")
Cc: Kees Cook
Signed-off-by: Mathias Krause
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
commit 4943ba16bbc2db05115707b3ff7b4874e9e3c560 upstream.
This adds the module loading prefix "crypto-" to the template lookup
as well.For example, attempting to load 'vfat(blowfish)' via AF_ALG now correctly
includes the "crypto-" prefix at every level, correctly rejecting "vfat":net-pf-38
algif-hash
crypto-vfat(blowfish)
crypto-vfat(blowfish)-all
crypto-vfatReported-by: Mathias Krause
Signed-off-by: Kees Cook
Acked-by: Mathias Krause
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
commit 5d26a105b5a73e5635eae0629b42fa0a90e07b7b upstream.
This prefixes all crypto module loading with "crypto-" so we never run
the risk of exposing module auto-loading to userspace via a crypto API,
as demonstrated by Mathias Krause:https://lkml.org/lkml/2013/3/4/70
Signed-off-by: Kees Cook
Signed-off-by: Herbert Xu
Signed-off-by: Greg Kroah-Hartman -
commit 175f8e2650f7ca6b33d338be3ccc1c00e89594ea upstream.
In some cases acpi_device_wakeup() may be called to ensure wakeup
power to be off for a given device even though that device's wakeup
GPE has not been enabled so far. It calls acpi_disable_gpe() on a
GPE that's not enabled and this causes ACPICA to return the AE_LIMIT
status code from that call which then is reported as an error by the
ACPICA's debug facilities (if enabled). This may lead to a fair
amount of confusion, so introduce a new ACPI device wakeup flag
to store the wakeup GPE status and avoid disabling wakeup GPEs
that have not been enabled.Reported-and-tested-by: Venkat Raghavulu
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit 7e2a38831db4cf082aa8b4997f3cbfe8cb03b669 upstream.
Add a flag that enables match found notification to align with
FW API change.Signed-off-by: David Spinadel
Signed-off-by: Emmanuel Grumbach
Signed-off-by: Greg Kroah-Hartman -
commit dbdd74763f1faf799fbb9ed30423182e92919378 upstream.
This reverts commit 2c3fc8d26dd09b9d7069687eead849ee81c78e46.
This commit broke on x86 PV because entries in the generic SWIOTLB are
indexed using (pseudo-)physical address not DMA address and these are
not the same in a x86 PV guest.Signed-off-by: David Vrabel
Reviewed-by: Stefano Stabellini
Signed-off-by: Greg Kroah-Hartman -
commit 3b05ac3824ed9648c0d9c02d51d9b54e4e7e874f upstream.
The app_tcp_pkt_out() function expects "*diff" to be set and ends up
using uninitialized data if CONFIG_IP_VS_IPV6 is turned on.The same issue is there in app_tcp_pkt_in(). Thanks to Julian Anastasov
for noticing that.Signed-off-by: Dan Carpenter
Acked-by: Julian Anastasov
Signed-off-by: Simon Horman
Signed-off-by: Greg Kroah-Hartman -
commit 8ca3f5e974f2b4b7f711589f4abff920db36637a upstream.
Commit 5195c14c8b27c ("netfilter: conntrack: fix race in
__nf_conntrack_confirm against get_next_corpse") aimed to resolve the
race condition between the confirmation (packet path) and the flush
command (from control plane). However, it introduced a crash when
several packets race to add a new conntrack, which seems easier to
reproduce when nf_queue is in place.Fix this race, in __nf_conntrack_confirm(), by removing the CT
from unconfirmed list before checking the DYING bit. In case
race occured, re-add the CT to the dying listThis patch also changes the verdict from NF_ACCEPT to NF_DROP when
we lose race. Basically, the confirmation happens for the first packet
that we see in a flow. If you just invoked conntrack -F once (which
should be the common case), then this is likely to be the first packet
of the flow (unless you already called flush anytime soon in the past).
This should be hard to trigger, but better drop this packet, otherwise
we leave things in inconsistent state since the destination will likely
reply to this packet, but it will find no conntrack, unless the origin
retransmits.The change of the verdict has been discussed in:
https://www.marc.info/?l=linux-netdev&m=141588039530056&w=2Signed-off-by: Pablo Neira Ayuso
Signed-off-by: Greg Kroah-Hartman -
commit 62924af247e95de7041a6d6f2d06cdd05152e2dc upstream.
Relax the checking that was introduced in 97840cb ("netfilter:
nfnetlink: fix insufficient validation in nfnetlink_bind") when the
subscription bitmask is used. Existing userspace code code may request
to listen to all of the existing netlink groups by setting an all to one
subscription group bitmask. Netlink already validates subscription via
setsockopt() for us.Signed-off-by: Pablo Neira Ayuso
Signed-off-by: Greg Kroah-Hartman -
commit a2f18db0c68fec96631c10cad9384c196e9008ac upstream.
Jumping between chains doesn't mix well with flush ruleset. Rules
from a different chain and set elements may still refer to us.[ 353.373791] ------------[ cut here ]------------
[ 353.373845] kernel BUG at net/netfilter/nf_tables_api.c:1159!
[ 353.373896] invalid opcode: 0000 [#1] SMP
[ 353.373942] Modules linked in: intel_powerclamp uas iwldvm iwlwifi
[ 353.374017] CPU: 0 PID: 6445 Comm: 31c3.nft Not tainted 3.18.0 #98
[ 353.374069] Hardware name: LENOVO 5129CTO/5129CTO, BIOS 6QET47WW (1.17 ) 07/14/2010
[...]
[ 353.375018] Call Trace:
[ 353.375046] [] ? nf_tables_commit+0x381/0x540
[ 353.375101] [] nfnetlink_rcv+0x3d8/0x4b0
[ 353.375150] [] netlink_unicast+0x105/0x1a0
[ 353.375200] [] netlink_sendmsg+0x32e/0x790
[ 353.375253] [] sock_sendmsg+0x8e/0xc0
[ 353.375300] [] ? move_addr_to_kernel.part.20+0x19/0x70
[ 353.375357] [] ? move_addr_to_kernel+0x19/0x30
[ 353.375410] [] ? verify_iovec+0x42/0xd0
[ 353.375459] [] ___sys_sendmsg+0x3f0/0x400
[ 353.375510] [] ? native_sched_clock+0x2a/0x90
[ 353.375563] [] ? acct_account_cputime+0x17/0x20
[ 353.375616] [] ? account_user_time+0x88/0xa0
[ 353.375667] [] __sys_sendmsg+0x3d/0x80
[ 353.375719] [] ? int_check_syscall_exit_work+0x34/0x3d
[ 353.375776] [] SyS_sendmsg+0xd/0x20
[ 353.375823] [] system_call_fastpath+0x16/0x1bRelease objects in this order: rules -> sets -> chains -> tables, to
make sure no references to chains are held anymore.Reported-by: Asbjoern Sloth Toennesen
Signed-off-by: Pablo Neira Ayuso
Signed-off-by: Greg Kroah-Hartman -
commit 9ea2aa8b7dba9e99544c4187cc298face254569f upstream.
Make sure there is enough room for the nfnetlink header in the
netlink messages that are part of the batch. There is a similar
check in netlink_rcv_skb().Signed-off-by: Pablo Neira Ayuso
Signed-off-by: Greg Kroah-Hartman -
commit 45f87de57f8fad59302fd263dd81ffa4843b5b24 upstream.
Commit 2457aec63745 ("mm: non-atomically mark page accessed during page
cache allocation where possible") has added a separate parameter for
specifying gfp mask for radix tree allocations.Not only this is less than optimal from the API point of view because it
is error prone, it is also buggy currently because
grab_cache_page_write_begin is using GFP_KERNEL for radix tree and if
fgp_flags doesn't contain FGP_NOFS (mostly controlled by fs by
AOP_FLAG_NOFS flag) but the mapping_gfp_mask has __GFP_FS cleared then
the radix tree allocation wouldn't obey the restriction and might
recurse into filesystem and cause deadlocks. This is the case for most
filesystems unfortunately because only ext4 and gfs2 are using
AOP_FLAG_NOFS.Let's simply remove radix_gfp_mask parameter because the allocation
context is same for both page cache and for the radix tree. Just make
sure that the radix tree gets only the sane subset of the mask (e.g. do
not pass __GFP_WRITE).Long term it is more preferable to convert remaining users of
AOP_FLAG_NOFS to use mapping_gfp_mask instead and simplify this
interface even further.Reported-by: Dave Chinner
Signed-off-by: Michal Hocko
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit a3a8784454692dd72e5d5d34dcdab17b4420e74c upstream.
When a key is being garbage collected, it's key->user would get put before
the ->destroy() callback is called, where the key is removed from it's
respective tracking structures.This leaves a key hanging in a semi-invalid state which leaves a window open
for a different task to try an access key->user. An example is
find_keyring_by_name() which would dereference key->user for a key that is
in the process of being garbage collected (where key->user was freed but
->destroy() wasn't called yet - so it's still present in the linked list).This would cause either a panic, or corrupt memory.
Fixes CVE-2014-9529.
Signed-off-by: Sasha Levin
Signed-off-by: David Howells
Signed-off-by: Greg Kroah-Hartman -
commit 5c0b8e0de76a86edb99e46612fd9d341b4c4fa0a upstream.
This patch fixes the big endian mode issue with function
xgene_ahci_read_id.Signed-off-by: Suman Tripathi
Signed-off-by: Tejun Heo
Signed-off-by: Greg Kroah-Hartman -
commit 4aaa71873ddb9faf4b0c4826579e2f6d18ff9ab4 upstream.
DMA mapped IO should be unmapped on the error path in probe() and
unconditionally on remove().Fixes: 62936009f35a ([libata] Add 460EX on-chip SATA driver, sata_dwc_460ex)
Signed-off-by: Andy Shevchenko
Signed-off-by: Tejun Heo
Signed-off-by: Greg Kroah-Hartman -
commit 38a1dfda8e77d7ba74c94d06d8bc41ba98a4bc8c upstream.
Commit 0dbc6078c06bc0 ('x86, build, pci: Fix PCI_MSI build on !SMP')
introduced the dependency that X86_UP_APIC is only available when
PCI_MSI is false. This effectively prevents PCI_MSI support on 32bit
UP systems because it disables both APIC and IO-APIC. But APIC support
is architecturally required for PCI_MSI.The intention of the patch was to enforce APIC support when PCI_MSI is
enabled, but failed to do so.Remove the !PCI_MSI dependency from X86_UP_APIC and enforce
X86_UP_APIC when PCI_MSI support is enabled on 32bit UP systems.[ tglx: Massaged changelog ]
Fixes 0dbc6078c06bc0 'x86, build, pci: Fix PCI_MSI build on !SMP'
Signed-off-by: Bryan O'Donoghue
Suggested-by: Thomas Gleixner
Reviewed-by: Andy Shevchenko
Cc: Thomas Petazzoni
Link: http://lkml.kernel.org/r/1421967529-9037-1-git-send-email-pure.logic@nexus-software.ie
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit 3669ef9fa7d35f573ec9c0e0341b29251c2734a7 upstream.
The Witcher 2 did something like this to allocate a TLS segment index:
struct user_desc u_info;
bzero(&u_info, sizeof(u_info));
u_info.entry_number = (uint32_t)-1;syscall(SYS_set_thread_area, &u_info);
Strictly speaking, this code was never correct. It should have set
read_exec_only and seg_not_present to 1 to indicate that it wanted
to find a free slot without putting anything there, or it should
have put something sensible in the TLS slot if it wanted to allocate
a TLS entry for real. The actual effect of this code was to
allocate a bogus segment that could be used to exploit espfix.The set_thread_area hardening patches changed the behavior, causing
set_thread_area to return -EINVAL and crashing the game.This changes set_thread_area to interpret this as a request to find
a free slot and to leave it empty, which isn't *quite* what the game
expects but should be close enough to keep it working. In
particular, using the code above to allocate two segments will
allocate the same segment both times.According to FrostbittenKing on Github, this fixes The Witcher 2.
If this somehow still causes problems, we could instead allocate
a limit==0 32-bit data segment, but that seems rather ugly to me.Fixes: 41bdc78544b8 x86/tls: Validate TLS entries to protect espfix
Signed-off-by: Andy Lutomirski
Cc: torvalds@linux-foundation.org
Link: http://lkml.kernel.org/r/0cb251abe1ff0958b8e468a9a9a905b80ae3a746.1421954363.git.luto@amacapital.net
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit e30ab185c490e9a9381385529e0fd32f0a399495 upstream.
32-bit programs don't have an lm bit in their ABI, so they can't
reliably cause LDT_empty to return true without resorting to memset.
They shouldn't need to do this.This should fix a longstanding, if minor, issue in all 64-bit kernels
as well as a potential regression in the TLS hardening code.Fixes: 41bdc78544b8 x86/tls: Validate TLS entries to protect espfix
Signed-off-by: Andy Lutomirski
Cc: torvalds@linux-foundation.org
Link: http://lkml.kernel.org/r/72a059de55e86ad5e2935c80aa91880ddf19d07c.1421954363.git.luto@amacapital.net
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit 63ea0a49ae0b145b91ff2b070c01b66fc75854b9 upstream.
STR and SLDT with rip-relative operand can cause a host kernel oops.
Mark them as DstMem as well.Signed-off-by: Nadav Amit
Signed-off-by: Paolo Bonzini
Signed-off-by: Greg Kroah-Hartman -
commit f3747379accba8e95d70cec0eae0582c8c182050 upstream.
SYSENTER emulation is broken in several ways:
1. It misses the case of 16-bit code segments completely (CVE-2015-0239).
2. MSR_IA32_SYSENTER_CS is checked in 64-bit mode incorrectly (bits 0 and 1 can
still be set without causing #GP).
3. MSR_IA32_SYSENTER_EIP and MSR_IA32_SYSENTER_ESP are not masked in
legacy-mode.
4. There is some unneeded code.Fix it.
Signed-off-by: Nadav Amit
Signed-off-by: Paolo Bonzini
Signed-off-by: Greg Kroah-Hartman -
commit f285f4a21c3253887caceed493089ece17579d59 upstream.
On 64-bit, relocation is not required unless the load address gets
changed. Without this, relocations do unexpected things when the kernel
is above 4G.Reported-by: Baoquan He
Signed-off-by: Kees Cook
Tested-by: Thomas D.
Cc: Vivek Goyal
Cc: Jan Beulich
Cc: Junjie Mao
Cc: Andi Kleen
Link: http://lkml.kernel.org/r/20150116005146.GA4212@www.outflux.net
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit 520452172e6b318f3a8bd9d4fe1e25066393de25 upstream.
Many users see this message when booting without knowning that it is
of no importance and that TSC calibration may have succeeded by
another way.As explained by Paul Bolle in
http://lkml.kernel.org/r/1348488259.1436.22.camel@x61.thuisdomein"Fast TSC calibration failed" should not be considered as an error
since other calibration methods are being tried afterward. At most,
those send a warning if they fail (not an error). So let's change
the message from error to warning.[ tglx: Make if pr_info. It's really not important at all ]
Fixes: c767a54ba065 x86/debug: Add KERN_ to bare printks, convert printks to pr_
Signed-off-by: Alexandre Demers
Link: http://lkml.kernel.org/r/1418106470-6906-1-git-send-email-alexandre.f.demers@gmail.com
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit 32c6590d126836a062b3140ed52d898507987017 upstream.
The Hyper-V clocksource is continuous; mark it accordingly.
Signed-off-by: K. Y. Srinivasan
Acked-by: jasowang@redhat.com
Cc: gregkh@linuxfoundation.org
Cc: devel@linuxdriverproject.org
Cc: olaf@aepfle.de
Cc: apw@canonical.com
Link: http://lkml.kernel.org/r/1421108762-3331-1-git-send-email-kys@microsoft.com
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit 8c38d28ba8da98f7102c31d35359b4dbe9d1f329 upstream.
EXYNOS4_MCT_L_MASK is defined as 0xffffff00, so applying this bitmask
produces a number outside the range 0x00 to 0xff, which always results
in execution of the default switch statement.Obviously this is wrong and git history shows that the bitmask inversion
was incorrectly set during a refactoring of the MCT code.Fix this by putting the inversion at the correct position again.
Acked-by: Kukjin Kim
Reported-by: GP Orcullo
Reviewed-by: Doug Anderson
Signed-off-by: Tobias Jakobi
Signed-off-by: Daniel Lezcano
Signed-off-by: Greg Kroah-Hartman -
commit 4a0d3107d6b19125f21172c2b7d95f9c30ecaf6f upstream.
The mis-naming likely was a copy-and-paste effect.
Signed-off-by: Jan Beulich
Link: http://lkml.kernel.org/r/54B9408B0200007800055E8B@mail.emea.novell.com
Signed-off-by: Thomas Gleixner
Signed-off-by: Greg Kroah-Hartman -
commit 91d1179212161f220938198b742c328ad38fd0a3 upstream.
This patch makes the bitmask for AIC_SRCTYPE consistent
with that of its valid values, and prevents the priority
field at bits 2:0 from being clobbered by an incorrect
AND with the AIC_SRCTYPE mask.Signed-off-by: Gavin Li
Acked-by: Boris Brezillon
Acked-by: Nicolas Ferre
Link: https://lkml.kernel.org/r/1420598843-8409-1-git-send-email-gavinli@thegavinli.com
Signed-off-by: Jason Cooper
Signed-off-by: Greg Kroah-Hartman -
commit 378ff1a53b5724f3ac97b0aba3c9ecac072f6fcd upstream.
It really needs to check that src is non-directory *and* use
{un,}lock_two_nodirectories(). As it is, it's trivial to cause
double-lock (ioctl(fd, CIFS_IOC_COPYCHUNK_FILE, fd)) and if the
last argument is an fd of directory, we are asking for trouble
by violating the locking order - all directories go before all
non-directories. If the last argument is an fd of parent
directory, it has 50% odds of locking child before parent,
which will cause AB-BA deadlock if we race with unlink().Signed-off-by: Al Viro
Signed-off-by: Greg Kroah-Hartman -
commit 38bdf45f4aa5cb6186d50a29e6cbbd9d486a1519 upstream.
On Armada XP, 375 and 38x the MBus window 13 has the remap capability,
like windows 0 to 7. However, the mvebu-mbus driver isn't currently
taking into account this special case, which means that when window 13
is actually used, the remap registers are left to 0, making the device
using this MBus window unavailable.As a minimal fix for stable, don't use window 13. A full fix will
follow later.Fixes: fddddb52a6c ("bus: introduce an Marvell EBU MBus driver")
Reviewed-by: Thomas Petazzoni
Signed-off-by: Andrew Lunn
Signed-off-by: Greg Kroah-Hartman -
commit 8f1e8ee28660018a935c7576b9af8ffe1feab54c upstream.
The current hardware I/O coherency is known to cause problems with DMA
coherent buffers, as it still requires explicit I/O synchronization
barriers, which is not compatible with the semantics expected by the
Linux DMA coherent buffers API.So, in order to have enough time to validate a new solution based on
automatic I/O synchronization barriers, this commit disables hardware
I/O coherency entirely. Future patches will re-enable it.Signed-off-by: Thomas Petazzoni
Signed-off-by: Andrew Lunn
Signed-off-by: Greg Kroah-Hartman -
commit 7ecd0bde5bfea524a843ad8fa8cb66ccbce68779 upstream.
Currently PWM functionality is broken on mx25 due to the wrong assignment of the
PWM "per" clock.According to Documentation/devicetree/bindings/clock/imx25-clock.txt:
pwm_ipg_per 52,so update the pwm "per" to use 'pwm_ipg_per' instead of 'per10' clock.
With this change PWM can work fine on mx25.
Reported-by: Carlos Soto
Signed-off-by: Fabio Estevam
Signed-off-by: Shawn Guo
Signed-off-by: Greg Kroah-Hartman -
commit 5e5aeb4367b450a28f447f6d5ab57d8f2ab16a5f upstream.
Verify that the frequency value from userspace is valid and makes sense.
Unverified values can cause overflows later on.
Cc: Thomas Gleixner
Cc: Ingo Molnar
Signed-off-by: Sasha Levin
[jstultz: Fix up bug for negative values and drop redunent cap check]
Signed-off-by: John Stultz
Signed-off-by: Greg Kroah-Hartman -
commit 6ada1fc0e1c4775de0e043e1bd3ae9d065491aa5 upstream.
An unvalidated user input is multiplied by a constant, which can result in
an undefined behaviour for large values. While this is validated later,
we should avoid triggering undefined behaviour.Cc: Thomas Gleixner
Cc: Ingo Molnar
Signed-off-by: Sasha Levin
[jstultz: include trivial milisecond->microsecond correction noticed
by Andy]
Signed-off-by: John Stultz
Signed-off-by: Greg Kroah-Hartman -
commit 4b149e417463bbb6d1d9b805f729627ca2b54495 upstream.
commit 55601c9f2467 (arm: omap: intc: switch over
to linear irq domain) introduced a regression with
SDMA legacy driver because that driver strictly depends
on INTC's IRQs starting at NR_IRQs. Aparently
irq_domain_add_linear() won't guarantee that, since we see
a 7 IRQs difference when booting with and without the
commit cited above.Until arch/arm/plat-omap/dma.c is properly fixed, we
must maintain OMAP2/3 using irq_domain_add_legacy().A FIXME note was added so people know to delete that
code once that legacy DMA driver is fixed up.Fixes: 55601c9f2467 (arm: omap: intc: switch over to linear irq domain)
Tested-by: Aaro Koskinen
Tested-by: Tony Lindgren
Signed-off-by: Felipe Balbi
Link: https://lkml.kernel.org/r/1420576688-10604-1-git-send-email-balbi@ti.com
Signed-off-by: Jason Cooper
Signed-off-by: Greg Kroah-Hartman -
commit a59db67656021fa212e9b95a583f13c34eb67cd9 upstream.
Introduce a new variable to count the number of allocated migration
structures. The existing variable cache->nr_migrations became
overloaded. It was used to:i) track of the number of migrations in flight for the purposes of
quiescing during suspend.ii) to estimate the amount of background IO occuring.
Recent discard changes meant that REQ_DISCARD bios are processed with
a migration. Discards are not background IO so nr_migrations was not
incremented. However this could cause quiescing to complete early.(i) is now handled with a new variable cache->nr_allocated_migrations.
cache->nr_migrations has been renamed cache->nr_io_migrations.
cleanup_migration() is now called free_io_migration(), since it
decrements that variable.Also, remove the unused cache->next_migration variable that got replaced
with with prealloc_structs a while ago.Signed-off-by: Joe Thornber
Signed-off-by: Mike Snitzer
Signed-off-by: Greg Kroah-Hartman -
commit 9b1cc9f251affdd27f29fe46d0989ba76c33faf6 upstream.
If a DM table is reloaded with an inactive table when the device is not
suspended (normal procedure for LVM2), then there will be two dm-bufio
objects that can diverge. This can lead to a situation where the
inactive table uses bufio to read metadata at the same time the active
table writes metadata -- resulting in the inactive table having stale
metadata buffers once it is promoted to the active table slot.Fix this by using reference counting and a global list of cache metadata
objects to ensure there is only one metadata object per metadata device.Signed-off-by: Joe Thornber
Signed-off-by: Mike Snitzer
Signed-off-by: Greg Kroah-Hartman -
commit 6cf11ee6300f38b7cfc43af9b7be2afaa5e05869 upstream.
The locking scheme inside the vb2 thread is unsafe when stopping the
thread. In particular kthread_stop was called *after* internal data
structures were cleaned up instead of doing that before. In addition,
internal vb2 functions were called after threadio->stop was set to
true and vb2_internal_streamoff was called. This is also not allowed.All this led to a variety of race conditions and kernel warnings and/or
oopses.Fixed by moving the kthread_stop call up before the cleanup takes
place, and by checking threadio->stop before calling internal vb2
queuing operations.Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 721f3223f26bbe81c7e55f84188e74d99df50a16 upstream.
Unconditionally attaching Si2161/Si2165 demod driver
breaks Hauppauge WinTV Starburst.
So create own card entry for this.Add card name comments to the subsystem ids.
This fixes a regression introduced in 3.17 by
36efec48e2e6016e05364906720a0ec350a5d768 ([media] cx23885: Add si2165 support for HVR-5500)Signed-off-by: Matthias Schwarzott
Tested-by: Antti Palosaari
Signed-off-by: Hans Verkuil
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 6cdb08172bc89f0a39e1643c5e7eab362692fd1b upstream.
Fixes a race condition in abort handling that was injected
when multiple interrupt support was added. When only a single
interrupt is present, the adapter guarantees it will send
responses for aborted commands prior to the response for the
abort command itself. With multiple interrupts, these responses
generally come back on different interrupts, so we need to
ensure the abort thread waits until the aborted command is
complete so we don't perform a double completion. This race
condition was being hit frequently in environments which
were triggering command timeouts, which was resulting in
a double completion causing a kernel oops.Signed-off-by: Brian King
Reviewed-by: Wendy Xiong
Tested-by: Wendy Xiong
Signed-off-by: Christoph Hellwig
Signed-off-by: Greg Kroah-Hartman -
commit c3e59ee4e76686b0c84ca8faa1011d10cd4ca1b8 upstream.
Reports against the TL-WDN4800 card indicate that PCI bus reset of this
Atheros device cause system lock-ups and resets. I've also been able to
confirm this behavior on multiple systems. The device never returns from
reset and attempts to access config space of the device after reset result
in hangs. Blacklist bus reset for the device to avoid this issue.[bhelgaas: This regression appeared in v3.14. Andreas bisected it to
425c1b223dac ("PCI: Add Virtual Channel to save/restore support"), but we
don't understand the mechanism by which that commit affects the reset
path.][bhelgaas: changelog, references]
Link: http://lkml.kernel.org/r/20140923210318.498dacbd@dualc.maya.org
Reported-by: Andreas Hartmann
Tested-by: Andreas Hartmann
Signed-off-by: Alex Williamson
Signed-off-by: Bjorn Helgaas
Signed-off-by: Greg Kroah-Hartman
