commit dc51cd2570468bb7bcf1815a60929023316ca868
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date: Sun Aug 4 16:51:49 2013 +0800
Linux 3.10.5
commit b185162885bc2346101a7b79c7737d2683b44782
Author: Yinghai Lu <yinghai@kernel.org>
Date: Thu Jun 13 15:33:35 2013 -0700
x86: Fix /proc/mtrr with base/size more than 44bits
commit d5c78673b1b28467354c2c30c3d4f003666ff385 upstream.
On one sytem that mtrr range is more then 44bits, in dmesg we have
[ 0.000000] MTRR default type: write-back
[ 0.000000] MTRR fixed ranges enabled:
[ 0.000000] 00000-9FFFF write-back
[ 0.000000] A0000-BFFFF uncachable
[ 0.000000] C0000-DFFFF write-through
[ 0.000000] E0000-FFFFF write-protect
[ 0.000000] MTRR variable ranges enabled:
[ 0.000000] 0 [000080000000-0000FFFFFFFF] mask 3FFF80000000 uncachable
[ 0.000000] 1 [380000000000-38FFFFFFFFFF] mask 3F0000000000 uncachable
[ 0.000000] 2 [000099000000-000099FFFFFF] mask 3FFFFF000000 write-through
[ 0.000000] 3 [00009A000000-00009AFFFFFF] mask 3FFFFF000000 write-through
[ 0.000000] 4 [381FFA000000-381FFBFFFFFF] mask 3FFFFE000000 write-through
[ 0.000000] 5 [381FFC000000-381FFC0FFFFF] mask 3FFFFFF00000 write-through
[ 0.000000] 6 [0000AD000000-0000ADFFFFFF] mask 3FFFFF000000 write-through
[ 0.000000] 7 [0000BD000000-0000BDFFFFFF] mask 3FFFFF000000 write-through
[ 0.000000] 8 disabled
[ 0.000000] 9 disabled
but /proc/mtrr report wrong:
reg00: base=0x080000000 ( 2048MB), size= 2048MB, count=1: uncachable
reg01: base=0x80000000000 (8388608MB), size=1048576MB, count=1: uncachable
reg02: base=0x099000000 ( 2448MB), size= 16MB, count=1: write-through
reg03: base=0x09a000000 ( 2464MB), size= 16MB, count=1: write-through
reg04: base=0x81ffa000000 (8519584MB), size= 32MB, count=1: write-through
reg05: base=0x81ffc000000 (8519616MB), size= 1MB, count=1: write-through
reg06: base=0x0ad000000 ( 2768MB), size= 16MB, count=1: write-through
reg07: base=0x0bd000000 ( 3024MB), size= 16MB, count=1: write-through
reg08: base=0x09b000000 ( 2480MB), size= 16MB, count=1: write-combining
so bit 44 and bit 45 get cut off.
We have problems in arch/x86/kernel/cpu/mtrr/generic.c::generic_get_mtrr().
1. for base, we miss cast base_lo to 64bit before shifting.
Fix that by adding u64 casting.
2. for size, it only can handle 44 bits aka 32bits + page_shift
Fix that with 64bit mask instead of 32bit mask_lo, then range could be
more than 44bits.
At the same time, we need to update size_or_mask for old cpus that does
support cpuid 0x80000008 to get phys_addr. Need to set high 32bits
to all 1s, otherwise will not get correct size for them.
Also fix mtrr_add_page: it should check base and (base + size - 1)
instead of base and size, as base and size could be small but
base + size could bigger enough to be out of boundary. We can
use boot_cpu_data.x86_phys_bits directly to avoid size_or_mask.
So When are we going to have size more than 44bits? that is 16TiB.
after patch we have right ouput:
reg00: base=0x080000000 ( 2048MB), size= 2048MB, count=1: uncachable
reg01: base=0x380000000000 (58720256MB), size=1048576MB, count=1: uncachable
reg02: base=0x099000000 ( 2448MB), size= 16MB, count=1: write-through
reg03: base=0x09a000000 ( 2464MB), size= 16MB, count=1: write-through
reg04: base=0x381ffa000000 (58851232MB), size= 32MB, count=1: write-through
reg05: base=0x381ffc000000 (58851264MB), size= 1MB, count=1: write-through
reg06: base=0x0ad000000 ( 2768MB), size= 16MB, count=1: write-through
reg07: base=0x0bd000000 ( 3024MB), size= 16MB, count=1: write-through
reg08: base=0x09b000000 ( 2480MB), size= 16MB, count=1: write-combining
-v2: simply checking in mtrr_add_page according to hpa.
[ hpa: This probably wants to go into -stable only after having sat in
mainline for a bit. It is not a regression. ]
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Link: http://lkml.kernel.org/r/1371162815-29931-1-git-send-email-yinghai@kernel.org
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0915f45b1275f392665df955e2e93ec459dac538
Author: Xiong Zhang <xiong.y.zhang@intel.com>
Date: Fri Jul 5 18:53:29 2013 +0800
drm/i915: Correct obj->mm_list link to dev_priv->dev_priv->mm.inactive_list
commit 067556084a0e412013af6b0250a3143ae5afde6d upstream.
obj->mm_list link to dev_priv->mm.inactive_list/active_list
obj->global_list link to dev_priv->mm.unbound_list/bound_list
This regression has been introduced in
commit 93927ca52a55c23e0a6a305e7e9082e8411ac9fa
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Thu Jan 10 18:03:00 2013 +0100
drm/i915: Revert shrinker changes from "Track unbound pages"
Cc: stable@vger.kernel.org
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
[danvet: Add regression notice.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Zhouping Liu <zliu@redhat.com>
commit 2652eb4444fc2965a428a07123b877be1637711a
Author: Michael Witten <mfwitten@gmail.com>
Date: Wed Apr 17 02:23:16 2013 +0000
perf tools: Revert regression in configuration of Python support
commit a363a9da65d253fa7354ce5fd630f4f94df934cc upstream.
Among other things, the following:
commit 31160d7feab786c991780d7f0ce2755a469e0e5e
Date: Tue Jan 8 16:22:36 2013 -0500
perf tools: Fix GNU make v3.80 compatibility issue
attempts to aid the user by tapping into an existing error message,
as described in the commit message:
... Also fix an issue where _get_attempt was called with only
one argument. This prevented the error message from printing
the name of the variable that can be used to fix the problem.
or more precisely:
-$(if $($(1)),$(call _ge_attempt,$($(1)),$(1)),$(call _ge_attempt,$(2)))
+$(if $($(1)),$(call _ge_attempt,$($(1)),$(1)),$(call _ge_attempt,$(2),$(1)))
However, The "missing" argument was in fact missing on purpose; it's
absence is a signal that the error message should be skipped, because
the failure would be due to the default value, not any user-supplied
value. This can be seen in how `_ge_attempt' uses `gea_err' (in the
config/utilities.mak file):
_ge_attempt = $(if $(get-executable),$(get-executable),$(_gea_warn)$(call _gea_err,$(2)))
_gea_warn = $(warning The path '$(1)' is not executable.)
_gea_err = $(if $(1),$(error Please set '$(1)' appropriately))
That is, because the argument is no longer missing, the value `$(1)'
(associated with `_gea_err') always evaluates to true, thus always
triggering the error condition that is meant to be reserved for
only the case when a user explicitly supplies an invalid value.
Concretely, the result is a regression in the Makefile's configuration
of python support; rather than gracefully disable support when the
relevant executables cannot be found according to default values, the
build process halts in error as though the user explicitly supplied
the values.
This new commit simply reverts the offending one-line change.
Reported-by: Pekka Enberg <penberg@kernel.org>
Link: http://lkml.kernel.org/r/CAOJsxLHv17Ys3M7P5q25imkUxQW6LE_vABxh1N3Tt7Mv6Ho4iw@mail.gmail.com
Signed-off-by: Michael Witten <mfwitten@gmail.com>
Cc: Mark Brown <broonie@sirena.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit adb97c299904814edb0bb26ae894139ca46ae446
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date: Tue Jul 30 04:04:02 2013 +0000
iscsi-target: Fix iscsit_sequence_cmd reject handling for iser
commit 561bf15892375597ee59d473a704a3e634c4f311 upstream
This patch moves ISCSI_OP_REJECT failures into iscsit_sequence_cmd()
in order to avoid external iscsit_reject_cmd() reject usage for all
PDU types.
It also updates PDU specific handlers for traditional iscsi-target
code to not reset the session after posting a ISCSI_OP_REJECT during
setup.
(v2: Fix CMDSN_LOWER_THAN_EXP for ISCSI_OP_SCSI to call
target_put_sess_cmd() after iscsit_sequence_cmd() failure)
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Cc: Or Gerlitz <ogerlitz@mellanox.com>
Cc: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1aa58ccd029fc75c115ae35c3fcb4d43043c0725
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date: Tue Jul 30 04:04:01 2013 +0000
iscsi-target: Fix iscsit_add_reject* usage for iser
commit ba159914086f06532079fc15141f46ffe7e04a41 upstream
This patch changes iscsit_add_reject() + iscsit_add_reject_from_cmd()
usage to not sleep on iscsi_cmd->reject_comp to address a free-after-use
usage bug in v3.10 with iser-target code.
It saves ->reject_reason for use within iscsit_build_reject() so the
correct value for both transport cases. It also drops the legacy
fail_conn parameter usage throughput iscsi-target code and adds
two iscsit_add_reject_cmd() and iscsit_reject_cmd helper functions,
along with various small cleanups.
(v2: Re-enable target_put_sess_cmd() to be called from
iscsit_add_reject_from_cmd() for rejects invoked after
target_get_sess_cmd() has been called)
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Cc: Or Gerlitz <ogerlitz@mellanox.com>
Cc: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6655d76ecb91fa618c4d0d0dd653e94078b3f050
Author: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Date: Sun Jul 14 14:03:27 2013 +0300
radeon kms: do not flush uninitialized hotplug work
commit a01c34f72e7cd2624570818f579b5ab464f93de2 upstream.
Fix a warning from lockdep caused by calling flush_work() for
uninitialized hotplug work. Initialize hotplug_work, audio_work
and reset_work upon successful radeon_irq_kms_init() completion
and thus perform hotplug flush_work only when rdev->irq.installed
is true.
[ 4.790019] [drm] Loading CEDAR Microcode
[ 4.790943] r600_cp: Failed to load firmware "radeon/CEDAR_smc.bin"
[ 4.791152] [drm:evergreen_startup] *ERROR* Failed to load firmware!
[ 4.791330] radeon 0000:01:00.0: disabling GPU acceleration
[ 4.792633] INFO: trying to register non-static key.
[ 4.792792] the code is fine but needs lockdep annotation.
[ 4.792953] turning off the locking correctness validator.
[ 4.793114] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.11.0-rc0-dbg-10676-gfe56456-dirty #1816
[ 4.793314] Hardware name: Acer Aspire 5741G /Aspire 5741G , BIOS V1.20 02/08/2011
[ 4.793507] ffffffff821fd810 ffff8801530b9a18 ffffffff8160434e 0000000000000002
[ 4.794155] ffff8801530b9ad8 ffffffff810b8404 ffff8801530b0798 ffff8801530b0000
[ 4.794789] ffff8801530b9b00 0000000000000046 00000000000004c0 ffffffff00000000
[ 4.795418] Call Trace:
[ 4.795573] [<ffffffff8160434e>] dump_stack+0x4e/0x82
[ 4.795731] [<ffffffff810b8404>] __lock_acquire+0x1a64/0x1d30
[ 4.795893] [<ffffffff814a87f0>] ? dev_vprintk_emit+0x50/0x60
[ 4.796034] [<ffffffff810b8fb4>] lock_acquire+0xa4/0x200
[ 4.796216] [<ffffffff8106cd75>] ? flush_work+0x5/0x280
[ 4.796375] [<ffffffff8106cdad>] flush_work+0x3d/0x280
[ 4.796520] [<ffffffff8106cd75>] ? flush_work+0x5/0x280
[ 4.796682] [<ffffffff810b659d>] ? trace_hardirqs_on_caller+0xfd/0x1c0
[ 4.796862] [<ffffffff8131d775>] ? delay_tsc+0x95/0xf0
[ 4.797024] [<ffffffff8141bb8b>] radeon_irq_kms_fini+0x2b/0x70
[ 4.797186] [<ffffffff814557c9>] evergreen_init+0x2a9/0x2e0
[ 4.797347] [<ffffffff813ebb1f>] radeon_device_init+0x5ef/0x700
[ 4.797511] [<ffffffff81335bc7>] ? pci_find_capability+0x47/0x50
[ 4.797672] [<ffffffff813edaed>] radeon_driver_load_kms+0x8d/0x150
[ 4.797843] [<ffffffff813ce426>] drm_get_pci_dev+0x166/0x280
[ 4.798007] [<ffffffff8116cff5>] ? kfree+0xf5/0x2e0
[ 4.798168] [<ffffffff813ea298>] ? radeon_pci_probe+0x98/0xd0
[ 4.798329] [<ffffffff813ea2aa>] radeon_pci_probe+0xaa/0xd0
[ 4.798489] [<ffffffff81339404>] pci_device_probe+0x84/0xe0
[ 4.798644] [<ffffffff814ac7d6>] driver_probe_device+0x76/0x240
[ 4.798805] [<ffffffff814aca73>] __driver_attach+0x93/0xa0
[ 4.798948] [<ffffffff814ac9e0>] ? __device_attach+0x40/0x40
[ 4.799126] [<ffffffff814aa82b>] bus_for_each_dev+0x6b/0xb0
[ 4.799272] [<ffffffff814ac2be>] driver_attach+0x1e/0x20
[ 4.799434] [<ffffffff814abec0>] bus_add_driver+0x1f0/0x280
[ 4.799596] [<ffffffff814ad0e4>] driver_register+0x74/0x150
[ 4.799758] [<ffffffff8133923d>] __pci_register_driver+0x5d/0x60
[ 4.799936] [<ffffffff81d16efc>] ? ttm_init+0x67/0x67
[ 4.800081] [<ffffffff813ce655>] drm_pci_init+0x115/0x130
[ 4.800243] [<ffffffff81d16efc>] ? ttm_init+0x67/0x67
[ 4.800405] [<ffffffff81d16f98>] radeon_init+0x9c/0xba
[ 4.800586] [<ffffffff810002ca>] do_one_initcall+0xfa/0x150
[ 4.800746] [<ffffffff81073f60>] ? parse_args+0x120/0x330
[ 4.800909] [<ffffffff81cdafae>] kernel_init_freeable+0x111/0x191
[ 4.801052] [<ffffffff81cda87a>] ? do_early_param+0x88/0x88
[ 4.801233] [<ffffffff815fb670>] ? rest_init+0x140/0x140
[ 4.801393] [<ffffffff815fb67e>] kernel_init+0xe/0x180
[ 4.801556] [<ffffffff8160dcac>] ret_from_fork+0x7c/0xb0
[ 4.801718] [<ffffffff815fb670>] ? rest_init+0x140/0x140
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3d63d1e0fe8aeed27f6ef38fa6eaf518dee1bbab
Author: David Vrabel <david.vrabel@citrix.com>
Date: Fri Jul 19 15:51:58 2013 +0100
xen/evtchn: avoid a deadlock when unbinding an event channel
commit 179fbd5a45f0d4034cc6fd37b8d367a3b79663c4 upstream.
Unbinding an event channel (either with the ioctl or when the evtchn
device is closed) may deadlock because disable_irq() is called with
port_user_lock held which is also locked by the interrupt handler.
Think of the IOCTL_EVTCHN_UNBIND is being serviced, the routine has
just taken the lock, and an interrupt happens. The evtchn_interrupt
is invoked, tries to take the lock and spins forever.
A quick glance at the code shows that the spinlock is a local IRQ
variant. Unfortunately that does not help as "disable_irq() waits for
the interrupt handler on all CPUs to stop running. If the irq occurs
on another VCPU, it tries to take port_user_lock and can't because
the unbind ioctl is holding it." (from David). Hence we cannot
depend on the said spinlock to protect us. We could make it a system
wide IRQ disable spinlock but there is a better way.
We can piggyback on the fact that the existence of the spinlock is
to make get_port_user() checks be up-to-date. And we can alter those
checks to not depend on the spin lock (as it's protected by u->bind_mutex
in the ioctl) and can remove the unnecessary locking (this is
IOCTL_EVTCHN_UNBIND) path.
In the interrupt handler we cannot use the mutex, but we do not
need it.
"The unbind disables the irq before making the port user stale, so when
you clear it you are guaranteed that the interrupt handler that might
use that port cannot be running." (from David).
Hence this patch removes the spinlock usage on the teardown path
and piggybacks on disable_irq happening before we muck with the
get_port_user() data. This ensures that the interrupt handler will
never run on stale data.
Signed-off-by: David Vrabel <david.vrabel@citrix.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
[v1: Expanded the commit description a bit]
Signed-off-by: Jonghwan Choi <jhbird.choi@samsung.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d0f1a6e5be8d8ada73891832af1bd3ecb3f52bb7
Author: Al Viro <viro@zeniv.linux.org.uk>
Date: Sat Jul 20 03:13:55 2013 +0400
livelock avoidance in sget()
commit acfec9a5a892f98461f52ed5770de99a3e571ae2 upstream.
Eric Sandeen has found a nasty livelock in sget() - take a mount(2) about
to fail. The superblock is on ->fs_supers, ->s_umount is held exclusive,
->s_active is 1. Along comes two more processes, trying to mount the same
thing; sget() in each is picking that superblock, bumping ->s_count and
trying to grab ->s_umount. ->s_active is 3 now. Original mount(2)
finally gets to deactivate_locked_super() on failure; ->s_active is 2,
superblock is still ->fs_supers because shutdown will *not* happen until
->s_active hits 0. ->s_umount is dropped and now we have two processes
chasing each other:
s_active = 2, A acquired ->s_umount, B blocked
A sees that the damn thing is stillborn, does deactivate_locked_super()
s_active = 1, A drops ->s_umount, B gets it
A restarts the search and finds the same superblock. And bumps it ->s_active.
s_active = 2, B holds ->s_umount, A blocked on trying to get it
... and we are in the earlier situation with A and B switched places.
The root cause, of course, is that ->s_active should not grow until we'd
got MS_BORN. Then failing ->mount() will have deactivate_locked_super()
shut the damn thing down. Fortunately, it's easy to do - the key point
is that grab_super() is called only for superblocks currently on ->fs_supers,
so it can bump ->s_count and grab ->s_umount first, then check MS_BORN and
bump ->s_active; we must never increment ->s_count for superblocks past
->kill_sb(), but grab_super() is never called for those.
The bug is pretty old; we would've caught it by now, if not for accidental
exclusion between sget() for block filesystems; the things like cgroup or
e.g. mtd-based filesystems don't have anything of that sort, so they get
bitten. The right way to deal with that is obviously to fix sget()...
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ba9a3c3ce30b8c399d5bfeef1d48a26170dc499e
Author: Gianluca Anzolin <gianluca@sottospazio.it>
Date: Thu Jul 25 07:26:16 2013 +0200
tty_port: Fix refcounting leak in tty_port_tty_hangup()
commit 1d9e689c934bd5ecb0f273c6c65e0655c5cfee5f upstream.
The function tty_port_tty_hangup() could leak a reference to the tty_struct:
struct tty_struct *tty = tty_port_tty_get(port);
if (tty && (!check_clocal || !C_CLOCAL(tty))) {
tty_hangup(tty);
tty_kref_put(tty);
}
If tty != NULL and the second condition is false we never call tty_kref_put and
the reference is leaked.
Fix by always calling tty_kref_put() which accepts a NULL argument.
The patch fixes a regression introduced by commit aa27a094.
Acked-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk>
Signed-off-by: Gianluca Anzolin <gianluca@sottospazio.it>
Acked-by: Jiri Slaby <jslaby@suse.cz>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0bd6f78c3016704d2b6978eab835dcd0759dca36
Author: Oleg Nesterov <oleg@redhat.com>
Date: Wed Jul 31 13:53:28 2013 -0700
mm: mempolicy: fix mbind_range() && vma_adjust() interaction
commit 3964acd0dbec123aa0a621973a2a0580034b4788 upstream.
vma_adjust() does vma_set_policy(vma, vma_policy(next)) and this
is doubly wrong:
1. This leaks vma->vm_policy if it is not NULL and not equal to
next->vm_policy.
This can happen if vma_merge() expands "area", not prev (case 8).
2. This sets the wrong policy if vma_merge() joins prev and area,
area is the vma the caller needs to update and it still has the
old policy.
Revert commit 1444f92c8498 ("mm: merging memory blocks resets
mempolicy") which introduced these problems.
Change mbind_range() to recheck mpol_equal() after vma_merge() to fix
the problem that commit tried to address.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Steven T Hampson <steven.t.hampson@intel.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Andi Kleen <andi@firstfloor.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8fc2b1321b8fb0ed3d80de5303b8db99923bdecf
Author: Rong Wang <Rong.Wang@csr.com>
Date: Sun Jul 28 23:01:35 2013 +0800
usb: gadget: udc-core: fix the typo of udc state attribute
commit 1894870eb4240399fabc6f0cb8c6fff4e6edbe83 upstream.
The name of udc state attribute file under sysfs is registered as
"state", while usb_gadget_set_state take it as "status" when it's
going to update. This patch fixes the typo.
Signed-off-by: Rong Wang <Rong.Wang@csr.com>
Signed-off-by: Barry Song <Baohua.Song@csr.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2ff7687bca58a839fd36e5a0b167465b4fa8bf51
Author: Rick Farina (Zero_Chaos) <zerochaos@gentoo.org>
Date: Mon Jul 29 15:17:59 2013 -0400
USB: serial: ftdi_sio: add more RT Systems ftdi devices
commit fed1f1ed90bce42ea010e2904cbc04e7b8304940 upstream.
RT Systems makes many usb serial cables based on the ftdi_sio driver for
programming various amateur radios. This patch is a full listing of
their current product offerings and should allow these cables to all
be recognized.
Signed-off-by: Rick Farina (Zero_Chaos) <zerochaos@gentoo.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 758057d66f667d17034b6080d06a2c6b5b498544
Author: Larry Finger <Larry.Finger@lwfinger.net>
Date: Fri Jun 28 09:12:53 2013 -0500
rtlwifi: Initialize power-setting callback for USB devices
commit bcfb879432094c267c35a7ff75d953d3a66c193a upstream.
Commit a269913c5 entitled "rtlwifi: Rework rtl_lps_leave() and
rtl_lps_enter() to use work queue" has two bugs for USB drivers.
Firstly, the work queue in question was not initialized. Secondly,
the callback routine used by this queue is contained within the
file used for PCI devices. As a result, it is not available for
architectures without PCI hardware.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Reported-by: Richard Genoud <richard.genoud@gmail.com>
Tested-by: Richard Genoud <richard.genoud@gmail.com>
Cc: Richard Genoud <richard.genoud@gmail.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6f8bbaf568c7f2c497558bfd04654c0b9841ad57
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Tue Jul 30 00:22:53 2013 -0400
drm/radeon/atom: initialize more atom interpretor elements to 0
commit 42a21826dc54583cdb79cc8477732e911ac9c376 upstream.
The ProcessAuxChannel table on some rv635 boards assumes
the divmul members are initialized to 0 otherwise we get
an invalid fb offset since it has a bad mask set when
setting the fb base. While here initialize all the
atom interpretor elements to 0.
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=60639
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8414d407af75ccbd398898fdb108189afc22ded4
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Fri Jul 26 13:26:05 2013 -0400
drm/radeon: fix audio dto programming on DCE4+
commit 7d61d835824f73dc4097b51f800382467c8049c5 upstream.
We need to set the dto source before setting the
dividers otherwise we may get stability problems
with the dto leading to audio playback problems.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6a5213cb7db96dc498b6c3cf6642ab6c8b2e08a3
Author: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Date: Tue Jul 23 15:49:39 2013 +0200
drm/nouveau: fix semaphore dmabuf obj
commit 7a7da592cbb22a1d360638dbecc393470c5effe3 upstream.
Fixes some dmabuf object errors on nv50 chipset and below.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c9af307d38974264922d35c77bb71087d171f8f8
Author: Ben Widawsky <ben@bwidawsk.net>
Date: Tue Jul 30 16:27:57 2013 -0700
drm/i915: fix missed hunk after GT access breakage
commit e1b4d3036c07ff137955fb1c0197ab62534f46ec upstream.
Upon some code refactoring, a hunk was missed. This was fixed for
next, but missed the current trees, and hasn't yet been merged by Dave
Airlie. It is fixed in:
commit 907b28c56ea40629aa6595ddfa414ec2fc7da41c
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Jul 19 20:36:52 2013 +0100
drm/i915: Colocate all GT access routines in the same file
It is introduced by:
commit 181d1b9e31c668259d3798c521672afb8edd355c
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sun Jul 21 13:16:24 2013 +0200
drm/i915: fix up gt init sequence fallout
Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9682e399d77f9bc0a5c9230bd1d69a3e75572ef1
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sun Jul 21 13:16:24 2013 +0200
drm/i915: fix up gt init sequence fallout
commit 181d1b9e31c668259d3798c521672afb8edd355c upstream.
The regression fix for gen6+ rps fallout
commit 7dcd2677ea912573d9ed4bcd629b0023b2d11505
Author: Konstantin Khlebnikov <khlebnikov@openvz.org>
Date: Wed Jul 17 10:22:58 2013 +0400
drm/i915: fix long-standing SNB regression in power consumption after resume
unintentionally also changed the init sequence ordering between
gt_init and gt_reset - we need to reset BIOS damage like leftover
forcewake references before we run our own code. Otherwise we can get
nasty dmesg noise like
[drm:__gen6_gt_force_wake_mt_get] *ERROR* Timed out waiting for forcewake old ack to clear.
again. Since _reset suggests that we first need to have stuff
initialized (which isn't the case here) call it sanitze instead.
While at it also block out the rps disable introduced by the above
commit on ilk: We don't have any knowledge of ilk rps being broken in
similar ways. And the disable functions uses the default hw state
which is only read out when we're enabling rps. So essentially we've
been writing random grabage into that register.
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Konstantin Khlebnikov <khlebnikov@openvz.org>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Tested-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8bc91b60f77d174f2485e10be8708c2fd7b85bfb
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Jul 19 20:36:51 2013 +0100
drm/i915: Serialize almost all register access
commit a7cd1b8fea2f341b626b255d9898a5ca5fabbf0a upstream.
In theory, the different register blocks were meant to be only ever
touched when holding either the struct_mutex, mode_config.lock or even a
specific localised lock. This does not seem to be the case, and the
hardware reacts extremely badly if we attempt to concurrently access two
registers within the same cacheline.
The HSD suggests that we only need to do this workaround for display
range registers. However, upon review we need to serialize the multiple
stages in our register write functions - if only for preemption
protection.
Irrespective of the hardware requirements, the current io functions are
a little too loose with respect to the combination of pre- and
post-condition testing that we do in conjunction with the actual io. As
a result, we may be pre-empted and generate both false-postive and
false-negative errors.
Note well that this is a "90%" solution, there remains a few direct
users of ioread/iowrite which will be fixed up in the next few patches.
Since they are more invasive and that this simple change will prevent
almost all lockups on Haswell, we kept this patch simple to facilitate
backporting to stable.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=63914
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f12155987bdc8d175b41b2fcbd88e8788c1af92d
Author: Kamal Mostafa <kamal@canonical.com>
Date: Fri Jul 19 15:02:01 2013 -0700
drm/i915: quirk no PCH_PWM_ENABLE for Dell XPS13 backlight
commit e85843bec6c2ea7c10ec61238396891cc2b753a9 upstream.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=47941
BugLink: https://bugs.launchpad.net/bugs/1163720
BugLink: https://bugs.launchpad.net/bugs/1162026
Some machines suffer from non-functional backlight controls if
BLM_PCH_PWM_ENABLE is set, so provide a quirk to avoid doing so.
Apply this quirk to Dell XPS 13 models.
Tested-by: Eric Griffith <EGriffith92@gmail.com>
Tested-by: Kent Baxley <kent.baxley@canonical.com>
Signed-off-by: Kamal Mostafa <kamal@canonical.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 19a280cac37e30243023a7f53651504a135ac960
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Jul 17 14:51:28 2013 +0200
drm/i915: correctly restore fences with objects attached
commit 94a335dba34ff47cad3d6d0c29b452d43a1be3c8 upstream.
To avoid stalls we delay tiling changes and especially hold of
committing the new fence state for as long as possible.
Synchronization points are in the execbuf code and in our gtt fault
handler.
Unfortunately we've missed that tricky detail when adding proper fence
restore code in
commit 19b2dbde5732170a03bd82cc8bd442cf88d856f7
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Jun 12 10:15:12 2013 +0100
drm/i915: Restore fences after resume and GPU resets
The result was that we've restored fences for objects with no tiling,
since the object<->fence link still existed after resume. Now that
wouldn't have been too bad since any subsequent access would have
fixed things up, but if we've changed from tiled to untiled real havoc
happened:
The tiling stride is stored -1 in the fence register, so a stride of 0
resulted in all 1s in the top 32bits, and so a completely bogus fence
spanning everything from the start of the object to the top of the
GTT. The tell-tale in the register dumps looks like:
FENCE START 2: 0x0214d001
FENCE END 2: 0xfffff3ff
Bit 11 isn't set since the hw doesn't store it, even when writing all
1s (at least on my snb here).
To prevent such a gaffle in the future add a sanity check for fences
with an untiled object attached in i915_gem_write_fence.
v2: Fix the WARN, spotted by Chris.
v3: Trying to reuse get_fences looked ugly and obfuscated the code.
Instead reuse update_fence and to make it really dtrt also move the
fence dirty state clearing into update_fence.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60530
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Matthew Garrett <matthew.garrett@nebula.com>
Tested-by: Björn Bidar <theodorstormgrade@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6f973258b047d2913abe2bd1aad95f21cb47d5f6
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Jul 17 12:14:40 2013 +0100
drm/i915: Fix dereferencing invalid connectors in is_crtc_connector_off()
commit 2e57f47d317dd035b18634b0c602272529368fcc upstream.
In commit e3de42b68478a8c95dd27520e9adead2af9477a5
Author: Imre Deak <imre.deak@intel.com>
Date: Fri May 3 19:44:07 2013 +0200
drm/i915: force full modeset if the connector is in DPMS OFF mode
a new function was added that walked over the set of connectors to see
if any of the currently associated CRTC was switched off. This function
walked an array of connectors, rather than the array of pointers to
connectors contained in the drm_mode_set - i.e. it was dereferencing far
past the end of the first connector. This only becomes an issue if we
attempt to use a clone mode (i.e. more than one connector per CRTC) such
that set->num_connectors > 1.
Reported-by: Timo Aaltonen <tjaalton@ubuntu.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=65927
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Egbert Eich <eich@suse.de>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f4332be72bc7a2095a21057e9db2c38bd44486b2
Author: Konstantin Khlebnikov <khlebnikov@openvz.org>
Date: Wed Jul 17 10:22:58 2013 +0400
drm/i915: fix long-standing SNB regression in power consumption after resume v2
commit 7dcd2677ea912573d9ed4bcd629b0023b2d11505 upstream.
This patch fixes regression in power consumtion of sandy bridge gpu, which
exists since v3.6 Sometimes after resuming from s2ram gpu starts thinking that
it's extremely busy. After that it never reaches rc6 state.
Bug exists since kernel v3.6:
commit b4ae3f22d238617ca11610b29fde16cf8c0bc6e0
Author: Jesse Barnes <jbarnes@virtuousgeek.org>
Date: Thu Jun 14 11:04:48 2012 -0700
drm/i915: load boot context at driver init time
For some reason RC6 is already enabled at the beginning of resuming process.
Following initliaztion breaks some internal state and confuses RPS engine.
This patch disables RC6 at the beginnig of resume and initialization.
I've rearranged initialization sequence, because intel_disable_gt_powersave()
needs initialized force_wake_get/put and some locks from the dev_priv.
Note: The culprit in the initialization sequence seems to be the write
to MBCTL added in the above mentioned commit. The first version of
this patch just held a forcewake reference across the clock gating
init functions, which seems to have been enought to gather quite a few
positive test reports. But since that smelled a bit like ad-hoc
duct-tape v2 now just disables rps/rc6 across the entire hw setup.
[danvet: Add note about v1 vs. v2 of this patch and use standard
layout for the commit citation. Also add the tested-bys from v1 and a cc:
stable.]
References https://bugs.freedesktop.org/show_bug.cgi?id=54089
References https://bugzilla.kernel.org/show_bug.cgi?id=58971
References https://patchwork.kernel.org/patch/2827634/ (patch v1)
Signed-off-by: Konstantin Khlebnikov <khlebnikov@openvz.org>
Tested-by: Alexander Kaltsas <alexkaltsas@gmail.com> (v1)
Tested-by: rocko <rockorequin@hotmail.com> (v1)
Tested-by: JohnMB <johnmbryant@sky.com> (v1)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1177b868c8b99fa8e4d88ef8b9542741b0d60055
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Wed Jul 10 13:36:23 2013 +0100
drm/i915: Fix incoherence with fence updates on Sandybridge+
commit d18b9619034230b6f945e215276425636ca401fe upstream.
This hopefully fixes the root cause behind the workaround added in
commit 25ff1195f8a0b3724541ae7bbe331b4296de9c06
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Thu Apr 4 21:31:03 2013 +0100
drm/i915: Workaround incoherence between fences and LLC across multiple CPUs
Thanks to further investigation by Jon Bloomfield, he realised that
the 64-bit register might be broken up by the hardware into two 32-bit
writes (a problem we have encountered elsewhere). This non-atomicity
would then cause an issue where a second thread would see an
intermediate register state (new high dword, old low dword), and this
register would randomly be used in preference to its own thread register.
This would cause the second thread to read from and write into a fairly
random tiled location. Breaking the operation into 3 explicit 32-bit
updates (first disable the fence, poke the upper bits, then poke the lower
bits and enable) ensures that, given proper serialisation between the
32-bit register write and the memory transfer, that the fence value is
always consistent.
Armed with this knowledge, we can explain how the previous workaround
work. The key to the corruption is that a second thread sees an
erroneous fence register that conflicts and overrides its own. By
serialising the fence update across all CPUs, we have a small window
where no GTT access is occurring and so hide the potential corruption.
This also leads to the conclusion that the earlier workaround was
incomplete.
v2: Be overly paranoid about the order in which fence updates become
visible to the GPU to make really sure that we turn the fence off before
doing the update, and then only switch the fence on afterwards.
Signed-off-by: Jon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Carsten Emde <C.Emde@osadl.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8cdbac3c4f987bd260009d3a7b8c3c8c37b5acdb
Author: Guenter Roeck <linux@roeck-us.net>
Date: Tue Jul 9 16:00:31 2013 -0700
Partially revert "drm/i915: unconditionally use mt forcewake on hsw/ivb"
commit c11e5f35ab490bd30591563816fbc83526521777 upstream.
This patch partially reverts commit 36ec8f877481449bdfa072e6adf2060869e2b970 for
IvyBridge CPUs.
The original commit results in repeated 'Timed out waiting for forcewake old
ack to clear' messages on a Supermicro C7H61 board (BIOS version 2.00 and 2.00b)
with i7-3770K CPU. It ultimately results in a hangup if the system is highly
loaded. Reverting the commit for IvyBridge CPUs fixes the issue.
Issue a warning if the CPU is IvyBridge and mt forcewake is disabled, since
this condition can result in secondary issues.
v2: Only revert patch for Ivybridge CPUs
Issue info message if mt forcewake is disabled on Ivybridge
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=60541
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=66139
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c33535efc0e1a637a7dbad918e1a0bf5a692dcdd
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Tue Jul 9 09:22:39 2013 +0100
drm/i915: Fix write-read race with multiple rings
commit 02978ff57a5bdfbf703d2bc5a4d933a53ede3144 upstream.
Daniel noticed a problem where is we wrote to an object with ring A in
the middle of a very long running batch, then executed a quick batch on
ring B before a batch that reads from the same object, its obj->ring would
now point to ring B, but its last_write_seqno would be still relative to
ring A. This would allow for the user to read from the object before the
GPU had completed the write, as set_domain would only check that ring B
had passed the last_write_seqno.
To fix this simply (and inelegantly), we bump the last_write_seqno when
switching rings so that the last_write_seqno is always relative to the
current obj->ring.
This fixes igt/tests/gem_write_read_ring_switch.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
[danvet: Add note about the newly created igt which exercises this bug.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5ac4dd137c34860870e0c0438180c2836053eadf
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Fri Jul 5 23:39:50 2013 +0200
drm/i915: fix up ring cleanup for the i830/i845 CS tlb w/a
commit aaf8a5167291b65e9116cb8736d862965b57c13a upstream.
It's not a good idea to also run the pipe_control cleanup.
This regression has been introduced whith the original cs tlb w/a in
commit b45305fce5bb1abec263fcff9d81ebecd6306ede
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Mon Dec 17 16:21:27 2012 +0100
drm/i915: Implement workaround for broken CS tlb on i830/845
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=64610
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d54b22e585edd4401786e7c02cd85bc97fff5ffb
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Fri Jul 19 17:44:43 2013 -0400
drm/radeon: improve dac adjust heuristics for legacy pdac
commit 03ed8cf9b28d886c64c7e705c7bb1a365fd8fb95 upstream.
Hopefully avoid more quirks in the future due to bogus
vbios dac data.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 405a7ccac881355809e07a4f00e0e8528ee7cec5
Author: Mark Kettenis <kettenis@openbsd.org>
Date: Sun Jul 21 16:44:09 2013 -0400
drm/radeon: fix combios tables on older cards
commit cef1d00cd56f600121ad121875655ad410a001b8 upstream.
Noticed that my old Radeon 7500 hung after printing
drm: GPU not posted. posting now...
when it wasn't selected as the primary card the BIOS. Some digging
revealed that it was hanging in combios_parse_mmio_table() while
parsing the ASIC INIT 3 table. Looking at the BIOS ROM for the card,
it becomes obvious that there is no ASIC INIT 3 table in the BIOS.
The code is just processing random garbage. No surprise it hangs!
Why do I say that there is no ASIC INIT 3 table is the BIOS? This
table is found through the MISC INFO table. The MISC INFO table can
be found at offset 0x5e in the COMBIOS header. But the header is
smaller than that. The COMBIOS header starts at offset 0x126. The
standard PCI Data Structure (the bit that starts with 'PCIR') lives at
offset 0x180. That means that the COMBIOS header can not be larger
than 0x5a bytes and therefore cannot contain a MISC INFO table.
I looked at a dozen or so BIOS images, some my own, some downloaded from:
<http://www.techpowerup.com/vgabios/index.php?manufacturer=ATI&page=1>
It is fairly obvious that the size of the COMBIOS header can be found
at offset 0x6 of the header. Not sure if it is a 16-bit number or
just an 8-bit number, but that doesn't really matter since the tables
seems to be always smaller than 256 bytes.
So I think combios_get_table_offset() should check if the requested
table is present. This can be done by checking the offset against the
size of the header. See the diff below. The diff is against the WIP
OpenBSD codebase that roughly corresponds to Linux 3.8.13 at this
point. But I don't think this bit of the code changed much since
then.
For what it is worth:
Signed-off-by: Mark Kettenis <kettenis@openbsd.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d19ccc405c87c8ca17ea3e1091d6a6eb2d9ac674
Author: Ondrej Zary <linux@rainbow-software.org>
Date: Fri Jul 19 21:08:48 2013 +0200
drm/radeon: Another card with wrong primary dac adj
commit f7929f34fa0e0bb6736a2484fdc07d77a1653081 upstream.
Hello,
got another card with "too bright" problem:
Sapphire Radeon VE 7000 DDR (VGA+S-Video)
lspci -vnn:
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices [AMD] nee ATI RV100 QY [Radeon 7000/VE] [1002:5159] (prog-if 00 [VGA controller])
Subsystem: PC Partner Limited Sapphire Radeon VE 7000 DDR [174b:7c28]
The patch below fixes the problem for this card.
But I don't like the blacklist, couldn't some heuristic be used instead?
The interesting thing is that the manufacturer is the same as the other card
needing the same quirk. I wonder how many different types are broken this way.
The "wrong" ps2_pdac_adj value that comes from BIOS on this card is 0x300.
====================
drm/radeon: Add primary dac adj quirk for Sapphire Radeon VE 7000 DDR
Values from BIOS are wrong, causing too bright colors.
Use default values instead.
Signed-off-by: Ondrej Zary <linux@rainbow-software.org>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f57cb1a2d0e5d88484616285a91560a6f5555e68
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Thu Jul 18 11:13:53 2013 -0400
drm/radeon: fix endian issues with DP handling (v3)
commit 34be8c9af7b8728465963740fc11136ae90dfc36 upstream.
The atom interpreter expects data in LE format, so
swap the message buffer as apprioriate.
v2: properly handle non-dw aligned byte counts.
v3: properly handle remainder
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: Dong He <hedonghust@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f92c99de9db693786ffc0f44503eece2bc6a237a
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Fri Jul 12 15:46:09 2013 -0400
drm/radeon: allow selection of alignment in the sub-allocator
commit 6c4f978b357bc779c703fda1f200e9179623d3e9 upstream.
There are cases where we need more than 4k alignment. No
functional change with this commit.
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c35486752501196044bbc4a1c61c43f39b17c2ff
Author: Christian König <christian.koenig@amd.com>
Date: Fri Jul 12 10:05:47 2013 +0200
drm/radeon: fix UVD fence emit
commit c9a6ca4abd5f1978ef15b3ece3474f4372ae5fe7 upstream.
Currently doesn't matter cause we allocate the fence in the
lower 265MB anyway.
Reported-by: Frank Huang <FrankR.Huang@amd.com>
Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1b4eafabcef5a74ccbc6edd201353cf23046a5a5
Author: Alex Deucher <alexander.deucher@amd.com>
Date: Mon Jul 8 18:16:56 2013 -0400
drm/radeon/hdmi: make sure we have an afmt block assigned
commit c2b4cacfe9816c1fe378c785ce8a678cf0635ec6 upstream.
Prevents a segfault if an afmt block is not assigned to the
encoder such as in the LVDS or eDP case.
Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=66714
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit dabd2582219f0b1b1724a42e7be4045fa3686598
Author: Mikulas Patocka <mpatocka@redhat.com>
Date: Wed Jul 10 23:41:16 2013 +0100
dm verity: fix inability to use a few specific devices sizes
commit b1bf2de07271932326af847a3c6a01fdfd29d4be upstream.
Fix a boundary condition that caused failure for certain device sizes.
The problem is reported at
http://code.google.com/p/cryptsetup/issues/detail?id=160
For certain device sizes the number of hashes at a specific level was
calculated incorrectly.
It happens for example for a device with data and metadata block size 4096
that has 16385 blocks and algorithm sha256.
The user can test if he is affected by this bug by running the
"veritysetup verify" command and also by activating the dm-verity kernel
driver and reading the whole block device. If it passes without an error,
then the user is not affected.
The condition for the bug is:
Split the total number of data blocks (data_block_bits) into bit strings,
each string has hash_per_block_bits bits. hash_per_block_bits is
rounddown(log2(metadata_block_size/hash_digest_size)). Equivalently, you
can say that you convert data_blocks_bits to 2^hash_per_block_bits base.
If there some zero bit string below the most significant bit string and at
least one bit below this zero bit string is set, then the bug happens.
The same bug exists in the userspace veritysetup tool, so you must use
fixed veritysetup too if you want to use devices that are affected by
this boundary condition.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Cc: Milan Broz <gmazyland@gmail.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ba0e6dd5e64bbf820669f7451ac03f4f11cd64f7
Author: Mikulas Patocka <mpatocka@redhat.com>
Date: Wed Jul 10 23:41:15 2013 +0100
dm ioctl: set noio flag to avoid __vmalloc deadlock
commit 1c0e883e86ece31880fac2f84b260545d66a39e0 upstream.
Set noio flag while calling __vmalloc() because it doesn't fully respect
gfp flags to avoid a possible deadlock (see commit
502624bdad3dba45dfaacaf36b7d83e39e74b2d2).
This should be backported to stable kernels 3.8 and newer. The kernel 3.8
doesn't have memalloc_noio_save(), so we should set and restore process
flag PF_MEMALLOC instead.
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 565ff95cdc72f76d53d4e98d5e84254368b9a041
Author: Hannes Reinecke <hare@suse.de>
Date: Wed Jul 10 23:41:15 2013 +0100
dm mpath: fix ioctl deadlock when no paths
commit 6c182cd88d179cbbd06f4f8a8a19b6977940753f upstream.
When multipath needs to retry an ioctl the reference to the
current live table needs to be dropped. Otherwise a deadlock
occurs when all paths are down:
- dm_blk_ioctl takes a reference to the current table
and spins in multipath_ioctl().
- A new table is being loaded, but upon resume the process
hangs in dm_table_destroy() waiting for references to
drop to zero.
With this patch the reference to the old table is dropped
prior to retry, thereby avoiding the deadlock.
Signed-off-by: Hannes Reinecke <hare@suse.de>
Cc: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: Alasdair G Kergon <agk@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f03519471a796be1c6d2aa9871928139828550c5
Author: Lan Tianyu <tianyu.lan@intel.com>
Date: Tue Jul 16 10:07:21 2013 +0800
ACPI / video: ignore BIOS initial backlight value for Fujitsu E753
commit 9657a565a476d517451c10b0bcc106e300785aff upstream.
The BIOS of FUjitsu E753 reports an incorrect initial backlight value
for WIN8 compatible OS, causing backlight to be dark during startup.
This change causes the incorrect initial value from BIOS to be ignored.
References: https://bugzilla.kernel.org/show_bug.cgi?id=60161
Reported-and-tested-by: Jan Hinnerk Stosch <janhinnerk.stosch@gmail.com>
Signed-off-by: Lan Tianyu <tianyu.lan@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bf59e1292e96b3dd4a2c58bbe8ac21e24e71dc42
Author: Toshi Kani <toshi.kani@hp.com>
Date: Wed Jul 10 10:47:13 2013 -0600
ACPI / memhotplug: Fix a stale pointer in error path
commit d19f503e22316a84c39bc19445e0e4fdd49b3532 upstream.
device->driver_data needs to be cleared when releasing its data,
mem_device, in an error path of acpi_memory_device_add().
The function evaluates the _CRS of memory device objects, and fails
when it gets an unexpected resource or cannot allocate memory. A
kernel crash or data corruption may occur when the kernel accesses
the stale pointer.
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Reviewed-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 85471df478e22dd96ca4756789abc795683addc9
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date: Fri Jul 12 13:45:59 2013 +0200
ACPI / scan: Do not try to attach scan handlers to devices having them
commit 3a391a39593b48341f0908511590a6c0e55cc069 upstream.
In acpi_bus_device_attach(), if there is an ACPI device object
for the given handle and that device object has a scan handler
attached to it already, there's nothing more to do for that handle.
Moreover, if acpi_scan_attach_handler() is called then, it may
execute the .attach() callback of the ACPI scan handler already
attached to the device object and that may lead to interesting
breakage.
For this reason, make acpi_bus_device_attach() return success
immediately when the handle's device object has a scan handler
attached to it.
Reported-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 9d80c9e6f3345b343b9a095e8591f7c8a164b2c0
Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Date: Mon Jul 8 02:01:53 2013 +0200
ACPI / scan: Always call acpi_bus_scan() for bus check notifications
commit 8832f7e43fa7f0f19bd54e13766a825dd1ed4d6f upstream.
An ACPI_NOTIFY_BUS_CHECK notification means that we should scan the
entire namespace starting from the given handle even if the device
represented by that handle is present (other devices below it may
just have appeared).
For this reason, modify acpi_scan_bus_device_check() to always run
acpi_bus_scan() if the notification being handled is of type
ACPI_NOTIFY_BUS_CHECK.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Toshi Kani <toshi.kani@hp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8acd5b1eaaf5b06ca149e697ed2a017a748bcd57
Author: Daniel Mack <zonque@gmail.com>
Date: Thu Jul 4 13:11:03 2013 +0200
regmap: cache: bail in regmap_async_complete() for bus-less maps
commit f2e055e7c9c6084bfbaa68701e52562acf96419e upstream.
Commit f8bd822cb ("regmap: cache: Factor out block sync") made
regcache_rbtree_sync() call regmap_async_complete(), which in turn does
not check for map->bus before dereferencing it.
This causes a NULL pointer dereference on bus-less maps.
Signed-off-by: Daniel Mack <zonque@gmail.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e39992ecaa7230126f96285a19493a9883294fdf
Author: K. Y. Srinivasan <kys@microsoft.com>
Date: Sun Jul 14 22:38:12 2013 -0700
Drivers: hv: balloon: Do not post pressure status if interrupted
commit c5e2254f8d63a6654149aa32ac5f2b7dd66a976d upstream.
When we are posting pressure status, we may get interrupted and handle
the un-balloon operation. In this case just don't post the status as we
know the pressure status is stale.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7b7295e5a040abf574110c14de67e6b463a1d921
Author: K. Y. Srinivasan <kys@microsoft.com>
Date: Sun Jul 14 22:38:11 2013 -0700
Drivers: hv: balloon: Fix a bug in the hot-add code
commit ed07ec93e83ec471d365ce084e43ad90fd205903 upstream.
As we hot-add 128 MB chunks of memory, we wait to ensure that the memory
is onlined before attempting to hot-add the next chunk. If the udev rule for
memory hot-add is not executed within the allowed time, we would rollback the
state and abort further hot-add. Since the hot-add has succeeded and the only
failure is that the memory is not onlined within the allowed time, we should not
be rolling back the state. Fix this bug.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Acked-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0ac7e44316a38c618afb851e05e0b71d8c83fef7
Author: K. Y. Srinivasan <kys@microsoft.com>
Date: Thu Jul 11 12:03:31 2013 -0700
Tools: hv: KVP: Fix a bug in IPV6 subnet enumeration
commit ed4bb9744b41d39ba35080c2390e201575121dc7 upstream.
Each subnet string needs to be separated with a semicolon. Fix this bug.
Signed-off-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ce4eb5e3eda7c0b8f2eeb07d83c5857c7b373d8c
Author: Harshula Jayasuriya <harshula@redhat.com>
Date: Tue Jul 23 14:21:35 2013 +1000
nfsd: nfsd_open: when dentry_open returns an error do not propagate as struct file
commit e4daf1ffbe6cc3b12aab4d604e627829e93e9914 upstream.
The following call chain:
------------------------------------------------------------
nfs4_get_vfs_file
- nfsd_open
- dentry_open
- do_dentry_open
- __get_file_write_access
- get_write_access
- return atomic_inc_unless_negative(&inode->i_writecount) ? 0 : -ETXTBSY;
------------------------------------------------------------
can result in the following state:
------------------------------------------------------------
struct nfs4_file {
...
fi_fds = {0xffff880c1fa65c80, 0xffffffffffffffe6, 0x0},
fi_access = {{
counter = 0x1
}, {
counter = 0x0
}},
...
------------------------------------------------------------
1) First time around, in nfs4_get_vfs_file() fp->fi_fds[O_WRONLY] is
NULL, hence nfsd_open() is called where we get status set to an error
and fp->fi_fds[O_WRONLY] to -ETXTBSY. Thus we do not reach
nfs4_file_get_access() and fi_access[O_WRONLY] is not incremented.
2) Second time around, in nfs4_get_vfs_file() fp->fi_fds[O_WRONLY] is
NOT NULL (-ETXTBSY), so nfsd_open() is NOT called, but
nfs4_file_get_access() IS called and fi_access[O_WRONLY] is incremented.
Thus we leave a landmine in the form of the nfs4_file data structure in
an incorrect state.
3) Eventually, when __nfs4_file_put_access() is called it finds
fi_access[O_WRONLY] being non-zero, it decrements it and calls
nfs4_file_put_fd() which tries to fput -ETXTBSY.
------------------------------------------------------------
...
[exception RIP: fput+0x9]
RIP: ffffffff81177fa9 RSP: ffff88062e365c90 RFLAGS: 00010282
RAX: ffff880c2b3d99cc RBX: ffff880c2b3d9978 RCX: 0000000000000002
RDX: dead000000100101 RSI: 0000000000000001 RDI: ffffffffffffffe6
RBP: ffff88062e365c90 R8: ffff88041fe797d8 R9: ffff88062e365d58
R10: 0000000000000008 R11: 0000000000000000 R12: 0000000000000001
R13: 0000000000000007 R14: 0000000000000000 R15: 0000000000000000
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#9 [ffff88062e365c98] __nfs4_file_put_access at ffffffffa0562334 [nfsd]
#10 [ffff88062e365cc8] nfs4_file_put_access at ffffffffa05623ab [nfsd]
#11 [ffff88062e365ce8] free_generic_stateid at ffffffffa056634d [nfsd]
#12 [ffff88062e365d18] release_open_stateid at ffffffffa0566e4b [nfsd]
#13 [ffff88062e365d38] nfsd4_close at ffffffffa0567401 [nfsd]
#14 [ffff88062e365d88] nfsd4_proc_compound at ffffffffa0557f28 [nfsd]
#15 [ffff88062e365dd8] nfsd_dispatch at ffffffffa054543e [nfsd]
#16 [ffff88062e365e18] svc_process_common at ffffffffa04ba5a4 [sunrpc]
#17 [ffff88062e365e98] svc_process at ffffffffa04babe0 [sunrpc]
#18 [ffff88062e365eb8] nfsd at ffffffffa0545b62 [nfsd]
#19 [ffff88062e365ee8] kthread at ffffffff81090886
#20 [ffff88062e365f48] kernel_thread at ffffffff8100c14a
------------------------------------------------------------
Signed-off-by: Harshula Jayasuriya <harshula@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2b29b0d2f36f54034b7c038367f6b8e06bdc17ce
Author: Anton Blanchard <anton@samba.org>
Date: Mon Jul 15 14:04:50 2013 +1000
powerpc/modules: Module CRC relocation fix causes perf issues
commit 0e0ed6406e61434d3f38fb58aa8464ec4722b77e upstream.
Module CRCs are implemented as absolute symbols that get resolved by
a linker script. We build an intermediate .o that contains an
unresolved symbol for each CRC. genksysms parses this .o, calculates
the CRCs and writes a linker script that "resolves" the symbols to
the calculated CRC.
Unfortunately the ppc64 relocatable kernel sees these CRCs as symbols
that need relocating and relocates them at boot. Commit d4703aef
(module: handle ppc64 relocating kcrctabs when CONFIG_RELOCATABLE=y)
added a hook to reverse the bogus relocations. Part of this patch
created a symbol at 0x0:
# head -2 /proc/kallsyms
0000000000000000 T reloc_start
c000000000000000 T .__start
This reloc_start symbol is causing lots of confusion to perf. It
thinks reloc_start is a massive function that stretches from 0x0 to
0xc000000000000000 and we get various cryptic errors out of perf,
including:
problem incrementing symbol count, skipping event
This patch removes the reloc_start linker script label and instead
defines it as PHYSICAL_START. We also need to wrap it with
CONFIG_PPC64 because the ppc32 kernel can set a non zero
PHYSICAL_START at compile time and we wouldn't want to subtract
it from the CRCs in that case.
Signed-off-by: Anton Blanchard <anton@samba.org>
Acked-by: Rusty Russell <rusty@rustcorp.com.au>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 85acabeb3c8170634eb69bee29ad58eec6d05482
Author: Vakul Garg <vakul@freescale.com>
Date: Wed Jul 10 06:26:13 2013 +0000
crypto: caam - Fixed the memory out of bound overwrite issue
commit 9c23b7d3d6bda41e2a27375df705485523a96dc8 upstream.
When kernel is compiled with CONFIG_SLUB_DEBUG=y and
CRYPTO_MANAGER_DISABLE_TESTS=n, during kernel bootup, the kernel
reports error given below. The root cause is that in function
hash_digest_key(), for allocating descriptor, insufficient memory was
being allocated. The required number of descriptor words apart from
input and output pointers are 8 (instead of 6).
=============================================================================
BUG dma-kmalloc-32 (Not tainted): Redzone overwritten
-----------------------------------------------------------------------------
Disabling lock debugging due to kernel taint
INFO: 0xdec5dec0-0xdec5dec3. First byte 0x0 instead of 0xcc
INFO: Allocated in ahash_setkey+0x60/0x594 age=7 cpu=1 pid=1257
__kmalloc+0x154/0x1b4
ahash_setkey+0x60/0x594
test_hash+0x260/0x5a0
alg_test_hash+0x48/0xb0
alg_test+0x84/0x228
cryptomgr_test+0x4c/0x54
kthread+0x98/0x9c
ret_from_kernel_thread+0x64/0x6c
INFO: Slab 0xc0bd0ba0 objects=19 used=2 fp=0xdec5d0d0 flags=0x0081
INFO: Object 0xdec5dea0 @offset=3744 fp=0x5c200014
Bytes b4 dec5de90: 00 00 00 00 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a
........ZZZZZZZZ
Object dec5dea0: b0 80 00 0a 84 41 00 0d f0 40 00 00 00 67 3f c0
.....A...@...g?.
Object dec5deb0: 00 00 00 50 2c 14 00 50 f8 40 00 00 1e c5 d0 00
...P,..P.@......
Redzone dec5dec0: 00 00 00 14 ....
Padding dec5df68: 5a 5a 5a 5a 5a 5a 5a 5a
ZZZZZZZZ
Call Trace:
[dec65b60] [c00071b4] show_stack+0x4c/0x168 (unreliable)
[dec65ba0] [c00d4ec8] check_bytes_and_report+0xe4/0x11c
[dec65bd0] [c00d507c] check_object+0x17c/0x23c
[dec65bf0] [c0550a00] free_debug_processing+0xf4/0x294
[dec65c20] [c0550bdc] __slab_free+0x3c/0x294
[dec65c80] [c03f0744] ahash_setkey+0x4e0/0x594
[dec65cd0] [c01ef138] test_hash+0x260/0x5a0
[dec65e50] [c01ef4c0] alg_test_hash+0x48/0xb0
[dec65e70] [c01eecc4] alg_test+0x84/0x228
[dec65ee0] [c01ec640] cryptomgr_test+0x4c/0x54
[dec65ef0] [c005adc0] kthread+0x98/0x9c
[dec65f40] [c000e1ac] ret_from_kernel_thread+0x64/0x6c
FIX dma-kmalloc-32: Restoring 0xdec5dec0-0xdec5dec3=0xcc
Change-Id: I0c7a1048053e811025d1c3b487940f87345c8f5d
Signed-off-by: Vakul Garg <vakul@freescale.com>
Reviewed-by: Geanta Neag Horia Ioan-B05471 <horia.geanta@freescale.com>
Reviewed-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com>
Tested-by: Fleming Andrew-AFLEMING <AFLEMING@freescale.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a4208aa227113be2e0ea81613c4f15d3bc2fc768
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date: Fri Jul 12 09:39:03 2013 +0300
svcrdma: underflow issue in decode_write_list()
commit b2781e1021525649c0b33fffd005ef219da33926 upstream.
My static checker marks everything from ntohl() as untrusted and it
complains we could have an underflow problem doing:
return (u32 *)&ary->wc_array[nchunks];
Also on 32 bit systems the upper bound check could overflow.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2794edb180b726d9d8aedcc6c7034e2d877489fc
Author: Tejun Heo <tj@kernel.org>
Date: Mon Jul 22 16:53:36 2013 -0400
libata: make it clear that sata_inic162x is experimental
commit bb9696192826a7d9279caf872e95b41bc26c7eff upstream.
sata_inic162x never reached a state where it's reliable enough for
production use and data corruption is a relatively common occurrence.
Make the driver generate warning about the issues and mark the Kconfig
option as experimental.
If the situation doesn't improve, we'd be better off making it depend
on CONFIG_BROKEN. Let's wait for several cycles and see if the kernel
message draws any attention.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Martin Braure de Calignon <braurede@free.fr>
Reported-by: Ben Hutchings <ben@decadent.org.uk>
Reported-by: risc4all@yahoo.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b1cd27dc900443c2f40abe30d7c97c153b5e3e7d
Author: Youquan Song <youquan.song@intel.com>
Date: Thu Jul 11 21:15:57 2013 -0400
ata: Fix DVD not dectected at some platform with Wellsburg PCH
commit eac27f04a71e1f39f196f7e520d16dcefc955d77 upstream.
There is a patch b55f84e2d527182e7c611d466cd0bb6ddce201de "ata_piix: Fix DVD
not dectected at some Haswell platforms" to fix an issue of DVD not
recognized on Haswell Desktop platform with Lynx Point.
Recently, it is also found the same issue at some platformas with Wellsburg PCH.
So deliver a similar patch to fix it by disables 32bit PIO in IDE mode.
Signed-off-by: Youquan Song <youquan.song@intel.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5a4de615144fd87589783402cab3ecbc29865fc8
Author: NeilBrown <neilb@suse.de>
Date: Wed Jul 24 15:37:42 2013 +1000
md/raid10: remove use-after-free bug.
commit 0eb25bb027a100f5a9df8991f2f628e7d851bc1e upstream.
We always need to be careful when calling generic_make_request, as it
can start a chain of events which might free something that we are
using.
Here is one place I wasn't careful enough. If the wbio2 is not in
use, then it might get freed at the first generic_make_request call.
So perform all necessary tests first.
This bug was introduced in 3.3-rc3 (24afd80d99) and can cause an
oops, so fix is suitable for any -stable since then.
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c1dadcc1086bbbac1b5eeb4d5e157c76f2d8dfba
Author: NeilBrown <neilb@suse.de>
Date: Mon Jul 22 12:57:21 2013 +1000
md/raid5: fix interaction of 'replace' and 'recovery'.
commit f94c0b6658c7edea8bc19d13be321e3860a3fa54 upstream.
If a device in a RAID4/5/6 is being replaced while another is being
recovered, then the writes to the replacement device currently don't
happen, resulting in corruption when the replacement completes and the
new drive takes over.
This is because the replacement writes are only triggered when
's.replacing' is set and not when the similar 's.sync' is set (which
is the case during resync and recovery - it means all devices need to
be read).
So schedule those writes when s.replacing is set as well.
In this case we cannot use "STRIPE_INSYNC" to record that the
replacement has happened as that is needed for recording that any
parity calculation is complete. So introduce STRIPE_REPLACED to
record if the replacement has happened.
For safety we should also check that STRIPE_COMPUTE_RUN is not set.
This has a similar effect to the "s.locked == 0" test. The latter
ensure that now IO has been flagged but not started. The former
checks if any parity calculation has been flagged by not started.
We must wait for both of these to complete before triggering the
'replace'.
Add a similar test to the subsequent check for "are we finished yet".
This possibly isn't needed (is subsumed in the STRIPE_INSYNC test),
but it makes it more obvious that the REPLACE will happen before we
think we are finished.
Finally if a NeedReplace device is not UPTODATE then that is an
error. We really must trigger a warning.
This bug was introduced in commit 9a3e1101b827a59ac9036a672f5fa8d5279d0fe2
(md/raid5: detect and handle replacements during recovery.)
which introduced replacement for raid5.
That was in 3.3-rc3, so any stable kernel since then would benefit
from this fix.
Reported-by: qindehua <13691222965@163.com>
Tested-by: qindehua <qindehua@163.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8afb90da9f16abc5e577318544419bfcf3565391
Author: NeilBrown <neilb@suse.de>
Date: Wed Jul 17 15:19:29 2013 +1000
md/raid1: fix bio handling problems in process_checks()
commit 30bc9b53878a9921b02e3b5bc4283ac1c6de102a upstream.
Recent change to use bio_copy_data() in raid1 when repairing
an array is faulty.
The underlying may have changed the bio in various ways using
bio_advance and these need to be undone not just for the 'sbio' which
is being copied to, but also the 'pbio' (primary) which is being
copied from.
So perform the reset on all bios that were read from and do it early.
This also ensure that the sbio->bi_io_vec[j].bv_len passed to
memcmp is correct.
This fixes a crash during a 'check' of a RAID1 array. The crash was
introduced in 3.10 so this is suitable for 3.10-stable.
Reported-by: Joe Lawrence <joe.lawrence@stratus.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 1d83ab8548ff19bad94dcae62ba13ea476974e7f
Author: NeilBrown <neilb@suse.de>
Date: Wed Jul 17 14:55:31 2013 +1000
md: Remove recent change which allows devices to skip recovery.
commit 5024c298311f3b97c85cb034f9edaa333fdb9338 upstream.
commit 7ceb17e87bde79d285a8b988cfed9eaeebe60b86
md: Allow devices to be re-added to a read-only array.
allowed a bit more than just that. It also allows devices to be added
to a read-write array and to end up skipping recovery.
This patch removes the offending piece of code pending a rewrite for a
subsequent release.
More specifically:
If the array has a bitmap, then the device will still need a bitmap
based resync ('saved_raid_disk' is set under different conditions
is a bitmap is present).
If the array doesn't have a bitmap, then this is correct as long as
nothing has been written to the array since the metadata was checked
by ->validate_super. However there is no locking to ensure that there
was no write.
Bug was introduced in 3.10 and causes data corruption so
patch is suitable for 3.10-stable.
Reported-by: Joe Lawrence <joe.lawrence@stratus.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 943741e352f8b0c524f542b93e8b62978dc0a9b0
Author: Kees Cook <keescook@chromium.org>
Date: Mon Jul 15 11:50:45 2013 -0700
x86: make sure IDT is page aligned
based on 4df05f361937ee86e5a8c9ead8aeb6a19ea9b7d7 upstream.
Since the IDT is referenced from a fixmap, make sure it is page aligned.
This avoids the risk of the IDT ever being moved in the bss and having
the mapping be offset, resulting in calling incorrect handlers. In the
current upstream kernel this is not a manifested bug, but heavily patched
kernels (such as those using the PaX patch series) did encounter this bug.
Signed-off-by: Kees Cook <keescook@chromium.org>
Reported-by: PaX Team <pageexec@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: Seiji Aguchi <seiji.aguchi@hds.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6d7d28443969512be95873d2fb155f4be9261ca5
Author: H. Peter Anvin <hpa@linux.intel.com>
Date: Fri Jul 12 16:48:12 2013 -0700
x86, suspend: Handle CPUs which fail to #GP on RDMSR
commit 5ff560fd48d5b3d82fa0c3aff625c9da1a301911 upstream.
There are CPUs which have errata causing RDMSR of a nonexistent MSR to
not fault. We would then try to WRMSR to restore the value of that
MSR, causing a crash. Specifically, some Pentium M variants would
have this problem trying to save and restore the non-existent EFER,
causing a crash on resume.
Work around this by making sure we can write back the result at
suspend time.
Huge thanks to Christian Sünkenberg for finding the offending erratum
that finally deciphered the mystery.
Reported-and-tested-by: Johan Heinrich <onny@project-insanity.org>
Debugged-by: Christian Sünkenberg <christian.suenkenberg@student.kit.edu>
Acked-by: Rafael J. Wysocki <rjw@sisk.pl>
Link: http://lkml.kernel.org/r/51DDC972.3010005@student.kit.edu
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 07221c8c2109ae56d9f83cd0644498069ed7cfed
Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Date: Wed Jan 16 11:33:52 2013 -0500
xen/blkback: Check device permissions before allowing OP_DISCARD
commit 604c499cbbcc3d5fe5fb8d53306aa0fae1990109 upstream.
We need to make sure that the device is not RO or that
the request is not past the number of sectors we want to
issue the DISCARD operation for.
This fixes CVE-2013-2140.
Acked-by: Jan Beulich <JBeulich@suse.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
[v1: Made it pr_warn instead of pr_debug]
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f4b5b99f18cd5984120ab2334aeadc5384f260cf
Author: Jan Beulich <JBeulich@suse.com>
Date: Wed Jul 17 08:09:37 2013 +0100
xen-netfront: pull on receive skb may need to happen earlier
commit 093b9c71b6e450e375f4646ba86faed0195ec7df upstream.
Due to commit 3683243b ("xen-netfront: use __pskb_pull_tail to ensure
linear area is big enough on RX") xennet_fill_frags() may end up
filling MAX_SKB_FRAGS + 1 fragments in a receive skb, and only reduce
the fragment count subsequently via __pskb_pull_tail(). That's a
result of xennet_get_responses() allowing a maximum of one more slot to
be consumed (and intermediately transformed into a fragment) if the
head slot has a size less than or equal to RX_COPY_THRESHOLD.
Hence we need to adjust xennet_fill_frags() to pull earlier if we
reached the maximum fragment count - due to the described behavior of
xennet_get_responses() this guarantees that at least the first fragment
will get completely consumed, and hence the fragment count reduced.
In order to not needlessly call __pskb_pull_tail() twice, make the
original call conditional upon the pull target not having been reached
yet, and defer the newly added one as much as possible (an alternative
would have been to always call the function right before the call to
xennet_fill_frags(), but that would imply more frequent cases of
needing to call it twice).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0183a8ee8c5621a84b0e4ba0b627af73f563e37c
Author: Josef Bacik <jbacik@fusionio.com>
Date: Wed Jul 17 19:30:20 2013 -0400
Btrfs: re-add root to dead root list if we stop dropping it
commit d29a9f629e009c9b90e5859bce581070fd6247fc upstream.
If we stop dropping a root for whatever reason we need to add it back to the
dead root list so that we will re-start the dropping next transaction commit.
The other case this happens is if we recover a drop because we will add a root
without adding it to the fs radix tree, so we can leak it's root and commit root
extent buffer, adding this to the dead root list makes this cleanup happen.
Thanks,
Reported-by: Alex Lyakas <alex.btrfs@zadarastorage.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 14e86565899d123a994d974560624b617d855ca8
Author: Josef Bacik <jbacik@fusionio.com>
Date: Mon Jul 15 12:41:42 2013 -0400
Btrfs: fix lock leak when resuming snapshot deletion
commit fec386ac1428f9c0e672df952cbca5cebd4e4e2f upstream.
We aren't setting path->locks[level] when we resume a snapshot deletion which
means we won't unlock the buffer when we free the path. This causes deadlocks
if we happen to re-allocate the block before we've evicted the extent buffer
from cache. Thanks,
Reported-by: Alex Lyakas <alex.btrfs@zadarastorage.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit db60e49ae570b342d63f0bbda4d35b85a392da25
Author: Stefan Behrens <sbehrens@giantdisaster.de>
Date: Thu Jul 4 16:14:23 2013 +0200
Btrfs: fix wrong write offset when replacing a device
commit 115930cb2d444a684975cf2325759cb48ebf80cc upstream.
Miao Xie reported the following issue:
The filesystem was corrupted after we did a device replace.
Steps to reproduce:
# mkfs.btrfs -f -m single -d raid10 <device0>..<device3>
# mount <device0> <mnt>
# btrfs replace start -rfB 1 <device4> <mnt>
# umount <mnt>
# btrfsck <device4>
The reason for the issue is that we changed the write offset by mistake,
introduced by commit 625f1c8dc.
We read the data from the source device at first, and then write the
data into the corresponding place of the new device. In order to
implement the "-r" option, the source location is remapped using
btrfs_map_block(). The read takes place on the mapped location, and
the write needs to take place on the unmapped location. Currently
the write is using the mapped location, and this commit changes it
back by undoing the change to the write address that the aforementioned
commit added by mistake.
Reported-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: Stefan Behrens <sbehrens@giantdisaster.de>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit cb631ac7738411616e461ae43af9b6d4cb9d29d4
Author: Dirk Brandewie <dirk.j.brandewie@intel.com>
Date: Thu Jul 18 08:48:42 2013 -0700
cpufreq / intel_pstate: Change to scale off of max P-state
commit 2134ed4d614349b2b4e8d7bb593baa9179b8dd1e upstream.
Change to using max P-state instead of max turbo P-state. This
change resolves two issues.
On a quiet system intel_pstate can fail to respond to a load change.
On CPU SKUs that have a limited number of P-states and no turbo range
intel_pstate fails to select the highest available P-state.
This change is suitable for stable v3.9+
References: https://bugzilla.kernel.org/show_bug.cgi?id=59481
Reported-and-tested-by: Arjan van de Ven <arjan@linux.intel.com>
Reported-and-tested-by: dsmythies@telus.net
Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit dbc31d4e7958e7539180b9f2d7c8446e4a0429d4
Author: Karlis Ogsts <karlis.ogsts@sonymobile.com>
Date: Mon Jul 22 13:51:42 2013 -0700
staging: android: logger: Correct write offset reset on error
commit 72bb99cfe9c57d2044445fb34bbc95b4c0bae6f2 upstream.
In the situation that a writer fails to copy data from userspace it will reset
the write offset to the value it had before it went to sleep. This discarding
any messages written while aquiring the mutex.
Therefore the reset offset needs to be retrieved after acquiring the mutex.
Cc: Android Kernel Team <kernel-team@android.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@sonymobile.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 867ea7111553d42d7a1545d1c69998a1a53b3166
Author: Ian Abbott <abbotti@mev.co.uk>
Date: Mon Jul 8 13:36:19 2013 +0100
staging: comedi: COMEDI_CANCEL ioctl should wake up read/write
commit 69acbaac303e8cb948801a9ddd0ac24e86cc4a1b upstream.
Comedi devices can do blocking read() or write() (or poll()) if an
asynchronous command has been set up, blocking for data (for read()) or
buffer space (for write()). Various events associated with the
asynchronous command will wake up the blocked reader or writer (or
poller). It is also possible to force the asynchronous command to
terminate by issuing a `COMEDI_CANCEL` ioctl. That shuts down the
asynchronous command, but does not currently wake up the blocked reader
or writer (or poller). If the blocked task could be woken up, it would
see that the command is no longer active and return. The caller of the
`COMEDI_CANCEL` ioctl could attempt to wake up the blocked task by
sending a signal, but that's a nasty workaround.
Change `do_cancel_ioctl()` to wake up the wait queue after it returns
from `do_cancel()`. `do_cancel()` can propagate an error return value
from the low-level comedi driver's cancel routine, but it always shuts
the command down regardless, so `do_cancel_ioctl()` can wake up he wait
queue regardless of the return value from `do_cancel()`.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2578ae7c4bbb8528caa3ea835c7451868b4f8607
Author: Ian Abbott <abbotti@mev.co.uk>
Date: Fri Jul 5 16:49:34 2013 +0100
staging: comedi: fix a race between do_cmd_ioctl() and read/write
commit 4b18f08be01a7b3c7b6df497137b6e3cb28adaa3 upstream.
`do_cmd_ioctl()` is called with the comedi device's mutex locked to
process the `COMEDI_CMD` ioctl to set up comedi's asynchronous command
handling on a comedi subdevice. `comedi_read()` and `comedi_write()`
are the `read` and `write` handlers for the comedi device, but do not
lock the mutex (for performance reasons, as some things can hold the
mutex for quite a long time).
There is a race condition if `comedi_read()` or `comedi_write()` is
running at the same time and for the same file object and comedi
subdevice as `do_cmd_ioctl()`. `do_cmd_ioctl()` sets the subdevice's
`busy` pointer to the file object way before it sets the `SRF_RUNNING` flag
in the subdevice's `runflags` member. `comedi_read() and
`comedi_write()` check the subdevice's `busy` pointer is pointing to the
current file object, then if the `SRF_RUNNING` flag is not set, will call
`do_become_nonbusy()` to shut down the asyncronous command. Bad things
can happen if the asynchronous command is being shutdown and set up at
the same time.
To prevent the race, don't set the `busy` pointer until
after the `SRF_RUNNING` flag has been set. Also, make sure the mutex is
held in `comedi_read()` and `comedi_write()` while calling
`do_become_nonbusy()` in order to avoid moving the race condition to a
point within that function.
Change some error handling `goto cleanup` statements in `do_cmd_ioctl()`
to simple `return -ERRFOO` statements as a result of changing when the
`busy` pointer is set.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5deba4cf6db86cc902526d8b08fc5d56e9d43994
Author: Alan Stern <stern@rowland.harvard.edu>
Date: Thu Jul 11 14:58:04 2013 -0400
USB: global suspend and remote wakeup don't mix
commit e583d9db9960cf40e0bc8afee4946baa9d71596e upstream.
The hub driver was recently changed to use "global" suspend for system
suspend transitions on non-SuperSpeed buses. This means that we don't
suspend devices individually by setting the suspend feature on the
upstream hub port; instead devices all go into suspend automatically
when the root hub stops transmitting packets. The idea was to save
time and to avoid certain kinds of wakeup races.
Now it turns out that many hubs are buggy; they don't relay wakeup
requests from a downstream port to their upstream port if the
downstream port's suspend feature is not set (depending on the speed
of the downstream port, whether or not the hub is enabled for remote
wakeup, and possibly other factors).
We can't have hubs dropping wakeup requests. Therefore this patch
goes partway back to the old policy: It sets the suspend feature for a
port if the device attached to that port or any of its descendants is
enabled for wakeup. People will still be able to benefit from the
time savings if they don't care about wakeup and leave it disabled on
all their devices.
In order to accomplish this, the patch adds a new field to the usb_hub
structure: wakeup_enabled_descendants is a count of how many devices
below a suspended hub are enabled for remote wakeup. A corresponding
new subroutine determines the number of wakeup-enabled devices at or
below an arbitrary suspended USB device.
This should be applied to the 3.10 stable kernel.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: Toralf Förster <toralf.foerster@gmx.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 889ba7bc28e5db5da40f648c91678dcc2d2837fd
Author: William Gulland <wgulland@google.com>
Date: Thu Jun 27 16:10:20 2013 -0700
usb: Clear both buffers when clearing a control transfer TT buffer.
commit 2c7b871b9102c497ba8f972aa5d38532f05b654d upstream.
Control transfers have both IN and OUT (or SETUP) packets, so when
clearing TT buffers for a control transfer it's necessary to send
two HUB_CLEAR_TT_BUFFER requests to the hub.
Signed-off-by: William Gulland <wgulland@google.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 909dccf772418ade21930910ab71327552049982
Author: Jóhann B. Guðmundsson <johannbg@fedoraproject.org>
Date: Thu Jul 4 21:47:52 2013 +0000
USB: misc: Add Manhattan Hi-Speed USB DVI Converter to sisusbvga
commit 58fc90db8261b571c026bb8bf23aad48a7233118 upstream.
Signed-off-by: Jóhann B. Guðmundsson <johannbg@fedoraproject.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 592bafa7e0741a4f211e61d5043f16cf59d0023c
Author: Johan Hovold <jhovold@gmail.com>
Date: Fri Jun 28 12:24:26 2013 +0200
USB: ti_usb_3410_5052: fix dynamic-id matching
commit 1fad56424f5ad3ce4973505a357212b2e2282b3f upstream.
The driver failed to take the dynamic ids into account when determining
the device type and therefore all devices were detected as 2-port
devices when using the dynamic-id interface.
Match on the usb-serial-driver field instead of doing redundant id-table
searches.
Reported-by: Anders Hammarquist <iko@iko.pp.se>
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 003dda8a8dedc8a2e90f33fd0745b9529afdf161
Author: Felipe Balbi <balbi@ti.com>
Date: Mon Jul 15 12:36:35 2013 +0300
usb: dwc3: gadget: don't prevent gadget from being probed if we fail
commit cdcedd6981194e511cc206887db661d016069d68 upstream.
In case we fail our ->udc_start() callback, we
should be ready to accept another modprobe following
the failed one.
We had forgotten to clear dwc->gadget_driver back
to NULL and, because of that, we were preventing
gadget driver modprobe from being retried.
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 41557736ac4acc112a1884177f62716c57852ddc
Author: Huang Rui <ray.huang@amd.com>
Date: Thu Jun 27 01:08:11 2013 +0800
usb: dwc3: fix wrong bit mask in dwc3_event_type
commit 1974d494dea05ea227cb42f5e918828801e237aa upstream.
Per dwc3 2.50a spec, the is_devspec bit is used to distinguish the
Device Endpoint-Specific Event or Device-Specific Event (DEVT). If the
bit is 1, the event is represented Device-Specific Event, then use
[7:1] bits as Device Specific Event to marked the type. It has 7 bits,
and we can see the reserved8_31 variable name which means from 8 to 31
bits marked reserved, actually there are 24 bits not 25 bits between
that. And 1 + 7 + 24 = 32, the event size is 4 byes.
So in dwc3_event_type, the bit mask should be:
is_devspec [0] 1 bit
type [7:1] 7 bits
reserved8_31 [31:8] 24 bits
This patch should be backported to kernels as old as 3.2, that contain
the commit 72246da40f3719af3bfd104a2365b32537c27d83 "usb: Introduce
DesignWare USB3 DRD Driver".
Signed-off-by: Huang Rui <ray.huang@amd.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a53338faf612c0f3c0c4031b6844963540979ac4
Author: Ruchika Kharwar <ruchika@ti.com>
Date: Thu Jul 4 00:59:34 2013 -0500
usb: dwc3: fix the error returned with usb3_phy failure
commit 315955d707b50c8aad20a32ec0dd4c9fe243cabe upstream.
When there is an error with the usb3_phy probe or absence, the error returned
is erroneously for usb2_phy.
Signed-off-by: Ruchika Kharwar <ruchika@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d3fe9f67d94aaba648a3df948750658059340cde
Author: Johan Hovold <jhovold@gmail.com>
Date: Mon Jul 1 14:03:33 2013 +0200
USB: mos7840: fix memory leak in open
commit 5f8a2e68b679b41cc8e9b642f2f5aa45dd678641 upstream.
Allocated urbs and buffers were never freed on errors in open.
Signed-off-by: Johan Hovold <jhovold@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c65b5f6ade7209fc5eda9f0779de4ee254a6bb78
Author: Roger Quadros <rogerq@ti.com>
Date: Tue Jul 9 17:03:50 2013 +0300
USB: EHCI: Fix resume signalling on remote wakeup
commit 47a64a13d54f6c669b00542848d5550be3d3310e upstream.
Set the ehci->resuming flag for the port we receive a remote
wakeup on so that resume signalling can be completed.
Without this, the root hub timer will not fire again to check
if the resume was completed and there will be a never-ending wait on
on the port.
This effect is only observed if the HUB IRQ IN does not come after we
have initiated the port resume.
Signed-off-by: Roger Quadros <rogerq@ti.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 5dbb5d4f24bf6862a888637b7506d1e04c2d2276
Author: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Date: Wed Jul 24 10:27:13 2013 -0700
xhci: Avoid NULL pointer deref when host dies.
commit 203a86613fb3bf2767335659513fa98563a3eb71 upstream.
When the host controller fails to respond to an Enable Slot command, and
the host fails to respond to the register write to abort the command
ring, the xHCI driver will assume the host is dead, and call
usb_hc_died().
The USB device's slot_id is still set to zero, and the pointer stored at
xhci->devs[0] will always be NULL. The call to xhci_check_args in
xhci_free_dev should have caught the NULL virt_dev pointer.
However, xhci_free_dev is designed to free the xhci_virt_device
structures, even if the host is dead, so that we don't leak kernel
memory. xhci_free_dev checks the return value from the generic
xhci_check_args function. If the return value is -ENODEV, it carries on
trying to free the virtual device.
The issue is that xhci_check_args looks at the host controller state
before it looks at the xhci_virt_device pointer. It will return -ENIVAL
because the host is dead, and xhci_free_dev will ignore the return
value, and happily dereference the NULL xhci_virt_device pointer.
The fix is to make sure that xhci_check_args checks the xhci_virt_device
pointer before it checks the host state.
See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1203453 for
further details. This patch doesn't solve the underlying issue, but
will ensure we don't see any more NULL pointer dereferences because of
the issue.
This patch should be backported to kernels as old as 3.1, that
contain the commit 7bd89b4017f46a9b92853940fd9771319acb578a "xhci: Don't
submit commands or URBs to halted hosts."
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Reported-by: Vincent Thiele <vincentthiele@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 10a1c13241f682cdc866f2aa8a0e5c5373470ecb
Author: Oleksij Rempel <linux@rempel-privat.de>
Date: Sun Jul 21 15:36:19 2013 +0200
xhci: fix null pointer dereference on ring_doorbell_for_active_rings
commit d66eaf9f89502971fddcb0de550b01fa6f409d83 upstream.
in some cases where device is attched to xhci port and do not responding,
for example ath9k_htc with stalled firmware, kernel will
crash on ring_doorbell_for_active_rings.
This patch check if pointer exist before it is used.
This patch should be backported to kernels as old as 2.6.35, that
contain the commit e9df17eb1408cfafa3d1844bfc7f22c7237b31b8 "USB: xhci:
Correct assumptions about number of rings per endpoint"
Signed-off-by: Oleksij Rempel <linux@rempel-privat.de>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a875d82eda58712d81caf78ebb515fb072187138
Author: George Cherian <george.cherian@ti.com>
Date: Mon Jul 1 10:59:12 2013 +0530
usb: host: xhci: Enable XHCI_SPURIOUS_SUCCESS for all controllers with xhci 1.0
commit 07f3cb7c28bf3f4dd80bfb136cf45810c46ac474 upstream.
Xhci controllers with hci_version > 0.96 gives spurious success
events on short packet completion. During webcam capture the
"ERROR Transfer event TRB DMA ptr not part of current TD" was observed.
The same application works fine with synopsis controllers hci_version 0.96.
The same issue is seen with Intel Pantherpoint xhci controller. So enabling
this quirk in xhci_gen_setup if controller verion is greater than 0.96.
For xhci-pci move the quirk to much generic place xhci_gen_setup.
Note from Sarah:
The xHCI 1.0 spec changed how hardware handles short packets. The HW
will notify SW of the TRB where the short packet occurred, and it will
also give a successful status for the last TRB in a TD (the one with the
IOC flag set). On the second successful status, that warning will be
triggered in the driver.
Software is now supposed to not assume the TD is not completed until it
gets that last successful status. That means we have a slight race
condition, although it should have little practical impact. This patch
papers over that issue.
It's on my long-term to-do list to fix this race condition, but it is a
much more involved patch that will probably be too big for stable. This
patch is needed for stable to avoid serious log spam.
This patch should be backported to kernels as old as 3.0, that
contain the commit ad808333d8201d53075a11bc8dd83b81f3d68f0b "Intel xhci:
Ignore spurious successful event."
The patch will have to be modified for kernels older than 3.2, since
that kernel added the xhci_gen_setup function for xhci platform devices.
The correct conflict resolution for kernels older than 3.2 is to set
XHCI_SPURIOUS_SUCCESS in xhci_pci_quirks for all xHCI 1.0 hosts.
Signed-off-by: George Cherian <george.cherian@ti.com>
Signed-off-by: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c62771c88704f0814d0fead60eadc0397a5e832f
Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
Date: Tue Jul 23 22:21:59 2013 -0400
tracing: Remove locking trace_types_lock from tracing_reset_all_online_cpus()
commit 09d8091c024ec88d1541d93eb8ddb2bd5cf10c39 upstream.
Commit a82274151af "tracing: Protect ftrace_trace_arrays list in trace_events.c"
added taking the trace_types_lock mutex in trace_events.c as there were
several locations that needed it for protection. Unfortunately, it also
encapsulated a call to tracing_reset_all_online_cpus() which also takes
the trace_types_lock, causing a deadlock.
This happens when a module has tracepoints and has been traced. When the
module is removed, the trace events module notifier will grab the
trace_types_lock, do a bunch of clean ups, and also clears the buffer
by calling tracing_reset_all_online_cpus. This doesn't happen often
which explains why it wasn't caught right away.
Commit a82274151af was marked for stable, which means this must be
sent to stable too.
Link: http://lkml.kernel.org/r/51EEC646.7070306@broadcom.com
Reported-by: Arend van Spril <arend@broadcom.com>
Tested-by: Arend van Spriel <arend@broadcom.com>
Cc: Alexander Z Lam <azl@google.com>
Cc: Vaibhav Nagarnaik <vnagarnaik@google.com>
Cc: David Sharp <dhsharp@google.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e55679914313bbfc003dcdf8ff74a16dec2fe24d
Author: Oleg Nesterov <oleg@redhat.com>
Date: Fri Jul 19 17:36:44 2013 +0200
tracing: Kill the unbalanced tr->ref++ in tracing_buffers_open()
commit e70e78e3c83b536730e31231dd9b979768d8df3c upstream.
tracing_buffers_open() does trace_array_get() and then it wrongly
inrcements tr->ref again under trace_types_lock. This means that
every caller leaks trace_array:
# cd /sys/kernel/debug/tracing/
# mkdir instances/X
# true < instances/X/per_cpu/cpu0/trace_pipe_raw
# rmdir instances/X
rmdir: failed to remove `instances/X': Device or resource busy
Link: http://lkml.kernel.org/r/20130719153644.GA18899@redhat.com
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e45ccd09b53e4cd60941891ad6992579ebc78024
Author: Alexander Z Lam <azl@google.com>
Date: Thu Jul 18 11:18:44 2013 -0700
tracing: Miscellaneous fixes for trace_array ref counting
commit f77d09a384676bde6445413949d9d2c508ff3e62 upstream.
Some error paths did not handle ref counting properly, and some trace files need
ref counting.
Link: http://lkml.kernel.org/r/1374171524-11948-1-git-send-email-azl@google.com
Signed-off-by: Alexander Z Lam <azl@google.com>
Cc: Vaibhav Nagarnaik <vnagarnaik@google.com>
Cc: David Sharp <dhsharp@google.com>
Cc: Alexander Z Lam <lambchop468@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a33eb1f5e1ae58418d9853c794a40d340605d752
Author: Alexander Z Lam <azl@google.com>
Date: Wed Jul 10 17:34:34 2013 -0700
tracing: Fix error handling to ensure instances can always be removed
commit 609e85a70bcd0eedf4ec60639dbcfb1ab011e054 upstream.
Remove debugfs directories for tracing instances during creation if an error
occurs causing the trace_array for that instance to not be added to
ftrace_trace_arrays. If the directory continues to exist after the error, it
cannot be removed because the respective trace_array is not in
ftrace_trace_arrays.
Link: http://lkml.kernel.org/r/1373502874-1706-2-git-send-email-azl@google.com
Signed-off-by: Alexander Z Lam <azl@google.com>
Cc: Vaibhav Nagarnaik <vnagarnaik@google.com>
Cc: David Sharp <dhsharp@google.com>
Cc: Alexander Z Lam <lambchop468@gmail.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 25ef812609dbc1a3db74f0f5912c94afdfd65d31
Author: Saurav Kashyap <saurav.kashyap@qlogic.com>
Date: Fri Jul 12 14:47:51 2013 -0400
SCSI: qla2xxx: Properly set the tagging for commands.
commit c3ccb1d7cf4c4549151876dd37c0944a682fd9e1 upstream.
This fixes a regression where Xyratex controllers and disks were lost by the
driver:
https://bugzilla.kernel.org/show_bug.cgi?id=59601
Reported-by: Jack Hill <jackhill@jackhill.us>
Signed-off-by: Saurav Kashyap <saurav.kashyap@qlogic.com>
Signed-off-by: Giridhar Malavali <giridhar.malavali@qlogic.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 8cf7b0b08a0bccbf3a72487b3b85ac233e83947f
Author: Ewan D. Milne <emilne@redhat.com>
Date: Fri Nov 2 09:38:34 2012 -0400
SCSI: sd: fix crash when UA received on DIF enabled device
commit 085b513f97d8d799d28491239be4b451bcd8c2c5 upstream.
sd_prep_fn will allocate a larger CDB for the command via mempool_alloc
for devices using DIF type 2 protection. This CDB was being freed
in sd_done, which results in a kernel crash if the command is retried
due to a UNIT ATTENTION. This change moves the code to free the larger
CDB into sd_unprep_fn instead, which is invoked after the request is
complete.
It is no longer necessary to call scsi_print_command separately for
this case as the ->cmnd will no longer be NULL in the normal code path.
Also removed conditional test for DIF type 2 when freeing the larger
CDB because the protection_type could have been changed via sysfs while
the command was executing.
Signed-off-by: Ewan D. Milne <emilne@redhat.com>
Acked-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit b01c4c2c2e5b7ecf14e10efabf65183d9565ff2f
Author: Jeff Skirvin <jeffrey.d.skirvin@intel.com>
Date: Thu Jul 11 17:18:58 2013 -0700
SCSI: isci: Fix a race condition in the SSP task management path
commit 96f15f29038e58e1b0a96483e2b369ff446becf1 upstream.
This commit fixes a race condition in the isci driver abort task and SSP
device task management path. The race is caused when an I/O termination
in the SCU hardware is necessary because of an SSP target timeout condition,
and the check of the I/O end state races against the HW-termination-driven
end state. The failure of the race meant that no TMF was sent to the device
to clean-up the pending I/O.
Signed-off-by: Jeff Skirvin <jeffrey.d.skirvin@intel.com>
Reviewed-by: Lukasz Dorau <lukasz.dorau@intel.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7ca674af75d75aa6755746327f1fd3222e54b338
Author: Gregory CLEMENT <gregory.clement@free-electrons.com>
Date: Wed May 15 09:39:17 2013 +0100
ARM: 7722/1: zImage: Convert 32bits memory size and address from ATAG to 64bits DTB
commit faefd550c45d8d314e8f260f21565320355c947f upstream.
When CONFIG_ARM_APPENDED_DTB is selected, if the bootloader provides
an ATAG_MEM it replaces the memory size and the memory address in the
memory node of the device tree. In the case of a system which can
handle more than 4GB, the memory node cell size is 4: each data
(memory size and memory address) are 64 bits and then use 2 cells.
The current code in atags_to_fdt.c made the assumption of a cell size
of 2 (one cell for the memory size and one cell for the memory
address), this leads to an improper write of the data and ends with a
boot hang.
This patch writes the memory size and the memory address on the memory
node in the device tree depending of the size of the memory node (32
bits or 64 bits).
It has been tested in the 2 cases:
- with a dtb using skeleton.dtsi
- and with a dtb using skeleton64.dtsi
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Willy Tarreau <w@1wt.eu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e1e97450a25d46c665a634f5073f9555236b7b0b
Author: Nicolin Chen <b42378@freescale.com>
Date: Fri Jun 14 12:34:50 2013 +0800
ASoC: wm8962: Remove remaining direct register cache accesses
commit 2e7ee15ced914e109a1a5b6dfcd463d846a13bd5 upstream.
Also fix return values for headphone switch updates.
Signed-off-by: Nicolin Chen <b42378@freescale.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bceb4eb2756a33f87dfb0b86bd01f2af4b4b81ac
Author: Richard Zhao <rizhao@nvidia.com>
Date: Sun Jul 21 10:34:09 2013 +0800
ASoC: tegra: correct playback_dma_data setup
commit 647ab784c507763bfda79155f125b6edd1244806 upstream.
The errors were caused by copy/paste mistake in below commit
since v3.10:
3489d50 ASoC: tegra: Use common DAI DMA data struct
It also corrects slave_id initialization in tegra20_ac97 driver.
Signed-off-by: Richard Zhao <rizhao@nvidia.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Lucas Stach <dev@lynxeye.de>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f7fce059bfbbf82f4889d367086402e81a79496b
Author: Chih-Chung Chang <chihchung@chromium.org>
Date: Mon Jul 15 09:38:46 2013 -0700
ASoC: max98088 - fix element type of the register cache.
commit cb6f66a2d278e57a6c9d8fb59bd9ebd8ab3965c2 upstream.
The registers of max98088 are 8 bits, not 16 bits. This bug causes the
contents of registers to be overwritten with bad values when the codec
is suspended and then resumed.
Signed-off-by: Chih-Chung Chang <chihchung@chromium.org>
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit ed44e4d734910894c6d822d5dfbbb800fa2238ba
Author: Fabio Estevam <fabio.estevam@freescale.com>
Date: Thu Jul 4 20:01:02 2013 -0300
ASoC: sglt5000: Fix the default value of CHIP_SSS_CTRL
commit 016fcab8ff46fca29375d484226ec91932aa4a07 upstream.
According to the sgtl5000 reference manual, the default value of CHIP_SSS_CTRL
is 0x10.
Reported-by: Oskar Schirmer <oskar@scara.com>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Mark Brown <broonie@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit f8c974f6fbdef40d37f957292f3238552a8d3598
Author: Clemens Ladisch <clemens@ladisch.de>
Date: Mon Jul 22 21:32:09 2013 +0200
firewire: fix libdc1394/FlyCap2 iso event regression
commit 0699a73af3811b66b1ab5650575acee5eea841ab upstream.
Commit 18d627113b83 (firewire: prevent dropping of completed iso packet
header data) was intended to be an obvious bug fix, but libdc1394 and
FlyCap2 depend on the old behaviour by ignoring all returned information
and thus not noticing that not all packets have been received yet. The
result was that the video frame buffers would be saved before they
contained the correct data.
Reintroduce the old behaviour for old clients.
Tested-by: Stepan Salenikovich <stepan.salenikovich@gmail.com>
Tested-by: Josep Bosch <jep250@gmail.com>
Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6d2c6593cf6592707c68e95f43982adbe573c6ac
Author: David Henningsson <david.henningsson@canonical.com>
Date: Fri Jun 28 11:09:56 2013 +0200
ALSA: hda - Guess what, it's two more Dell headset mic quirks
commit cd6fb6793a33e2b02af6e05a8d3f735f7c88a943 upstream.
Add two more machines that need quirks for headset mics to work.
Tested-by: Shawn Wang <shawn.wang@canonical.com>
BugLink: https://bugs.launchpad.net/bugs/1195636
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 49a845673d47cddd320ba9bd0d746c071d5ad39a
Author: David Henningsson <david.henningsson@canonical.com>
Date: Fri Jun 28 08:53:34 2013 +0200
ALSA: hda - Yet another Dell headset mic quirk
commit 6c29d68a82ec68db18241b818d03e7864c052be9 upstream.
This quirk is needed for the headset mic to work on this Dell
machine.
BugLink: https://bugs.launchpad.net/bugs/1195597
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit e1d2c40df6b0caed73187254e7be9af87cc98850
Author: Ren Bigcren <bigcren.ren@sonymobile.com>
Date: Tue Jul 2 13:34:30 2013 +0200
USB: storage: Add MicroVault Flash Drive to unusual_devs
commit e7a6121f4929c17215f0cdca3726f4bf3e4e9529 upstream.
The device report an error capacity when read_capacity_16().
Using read_capacity_10() can get the correct capacity.
Signed-off-by: Ren Bigcren <bigcren.ren@sonymobile.com>
Cc: Matthew Dharm <mdharm-usb@one-eyed-alien.net>
Signed-off-by: Oskar Andero <oskar.andero@sonymobile.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c6ccbb9b6e24e35d71fd8706dfc5a8eab07f6937
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date: Wed Jul 3 03:11:48 2013 -0700
iscsi-target: Fix ISCSI_OP_SCSI_TMFUNC handling for iser
commit 186a9647019587b3784694894c4d136fd00cfd7b upstream.
This patch adds target_get_sess_cmd reference counting for
iscsit_handle_task_mgt_cmd(), and adds a target_put_sess_cmd()
for the failure case.
It also fixes a bug where ISCSI_OP_SCSI_TMFUNC type commands
where leaking iscsi_cmd->i_conn_node and eventually triggering
an OOPs during struct isert_conn shutdown.
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit d9e507c05ca19ad2ec166577edd8b47e17c8961e
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date: Wed Jul 3 03:05:37 2013 -0700
iser-target: Fix session reset bug with RDMA_CM_EVENT_DISCONNECTED
commit b2cb96494d83b894a43ba8b9023eead8ff50684b upstream.
This patch addresses a bug where RDMA_CM_EVENT_DISCONNECTED may occur
before the connection shutdown has been completed by rx/tx threads,
that causes isert_free_conn() to wait indefinately on ->conn_wait.
This patch allows isert_disconnect_work code to invoke rdma_disconnect
when isert_disconnect_work() process context is started by client
session reset before isert_free_conn() code has been reached.
It also adds isert_conn->conn_mutex protection for ->state within
isert_disconnect_work(), isert_cq_comp_err() and isert_free_conn()
code, along with isert_check_state() for wait_event usage.
(v2: Add explicit iscsit_cause_connection_reinstatement call
during isert_disconnect_work() to force conn reset)
Cc: Or Gerlitz <ogerlitz@mellanox.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit a5d56a2217664c7bc06cb7deeac9a2a155ba4345
Author: Joern Engel <joern@logfs.org>
Date: Wed Jul 3 11:35:11 2013 -0400
iscsi-target: Fix tfc_tpg_nacl_auth_cit configfs length overflow
commit 0fbfc46fb0b2f543a8b539e94c6c293ebc0b05a6 upstream.
This patch fixes a potential buffer overflow while processing
iscsi_node_auth input for configfs attributes within NodeACL
tfc_tpg_nacl_auth_cit context.
Signed-off-by: Joern Engel <joern@logfs.org>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit fff98879381243f59b6e9f630d55312aa34a89c9
Author: Nicholas Bellinger <nab@linux-iscsi.org>
Date: Wed Jun 26 02:31:42 2013 -0700
iser-target: Fix isert_put_reject payload buffer post
commit 3df8f68aaf7ebe3d136a22262b41b350b0a1858b upstream.
This patch adds the missing isert_put_reject() logic to post
a outgoing payload buffer to hold the 48 bytes of original PDU
header request payload for the rejected cmd.
It also fixes ISTATE_SEND_REJECT handling in isert_response_completion()
-> isert_do_control_comp() code, and drops incorrect iscsi_cmd_t->reject_comp
usage.
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
Cc: Or Gerlitz <ogerlitz@mellanox.com>
Cc: Mike Christie <michaelc@cs.wisc.edu>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 78077c226f0ab20fcd0a85a8f0de42b96973382b
Author: Vineet Gupta <Vineet.Gupta1@synopsys.com>
Date: Wed Jul 3 15:03:31 2013 -0700
mm: fix the TLB range flushed when __tlb_remove_page() runs out of slots
commit e6c495a96ce02574e765d5140039a64c8d4e8c9e upstream.
zap_pte_range loops from @addr to @end. In the middle, if it runs out of
batching slots, TLB entries needs to be flushed for @start to @interim,
NOT @interim to @end.
Since ARC port doesn't use page free batching I can't test it myself but
this seems like the right thing to do.
Observed this when working on a fix for the issue at thread:
http://www.spinics.net/lists/linux-arch/msg21736.html
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Hugh Dickins <hughd@google.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Cc: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>