01 Apr, 2014
40 commits
-
commit f2be82b0058e90b5d9ac2cb896b4914276fb50ef upstream.
The check that makes sure that we have enough memory allocated to read
in the entire header of the message in question is currently busted.
It compares front_len of the incoming message with iov_len field of
ceph_msg::front structure, which is used primarily to indicate the
amount of data already read in, and not the size of the allocated
buffer. Under certain conditions (e.g. a short read from a socket
followed by that socket's shutdown and owning ceph_connection reset)
this results in a warning similar to[85688.975866] libceph: get_reply front 198 > preallocated 122 (4#0)
and, through another bug, leads to forever hung tasks and forced
reboots. Fix this by comparing front_len with front_alloc_len field of
struct ceph_msg, which stores the actual size of the buffer.Fixes: http://tracker.ceph.com/issues/5425
Signed-off-by: Ilya Dryomov
Reviewed-by: Sage Weil
Signed-off-by: Greg Kroah-Hartman -
commit 3f0a4ac55fe036902e3666be740da63528ad8639 upstream.
Rename front local variable to front_len in get_reply() to make its
purpose more clear.Signed-off-by: Ilya Dryomov
Reviewed-by: Sage Weil
Signed-off-by: Greg Kroah-Hartman -
commit 3cea4c3071d4e55e9d7356efe9d0ebf92f0c2204 upstream.
Rename front_max field of struct ceph_msg to front_alloc_len to make
its purpose more clear.Signed-off-by: Ilya Dryomov
Reviewed-by: Sage Weil
Signed-off-by: Greg Kroah-Hartman -
commit 2b6e0ca175fe4a20f21ba82b1e7ccc71029c4dd4 upstream.
In https://bugzilla.redhat.com/show_bug.cgi?id=994438 and
https://bugzilla.redhat.com/show_bug.cgi?id=970480 we
received different reports of e100 throwing the following
warning:[] ? pci_disable_device+0x85/0x90
[] warn_slowpath_fmt+0x33/0x40
[] pci_disable_device+0x85/0x90
[] __e100_shutdown+0x80/0x120 [e100]
[] ? check_preempt_curr+0x65/0x90
[] e100_suspend+0x16/0x30 [e100]
[] pci_legacy_suspend+0x2b/0xb0
[] ? wait_for_completion+0x1f/0xd0
[] ? pci_pm_poweroff+0xb0/0xb0
[] pci_pm_freeze+0x94/0xa0
[] dpm_run_callback+0x37/0x80
[] ? pm_wakeup_pending+0xc4/0x140
[] __device_suspend+0xb2/0x1f0
[] async_suspend+0x1f/0x90
[] async_run_entry_fn+0x35/0x140
[] ? wake_up_process+0x1f/0x40
[] process_one_work+0x115/0x370
[] ? start_worker+0x25/0x30
[] ? manage_workers.isra.27+0x1a5/0x250
[] worker_thread+0xfe/0x330
[] ? manage_workers.isra.27+0x250/0x250
[] kthread+0x94/0xa0
[] ret_from_kernel_thread+0x1b/0x28
[] ? insert_kthread_work+0x30/0x30This patch removes pci_disable_device() from __e100_shutdown().
pci_clear_master() is enough.Signed-off-by: Michele Baldessari
Tested-by: Mark Harig
Signed-off-by: Aaron Brown
Signed-off-by: David S. Miller
Cc: Josh Boyer
Signed-off-by: Greg Kroah-Hartman -
commit 1aa9578c1a9450fb21501c4f549f5b1edb557e6d upstream.
Don Zickus writes:
Some co-workers of mine bought Samsung laptops that had mostly usb3 ports.
Those ports did not resume correctly (the driver would timeout communicating
and fail). This led to frustration as suspend/resume is a common use for
laptops.Poking around, I applied the reset on resume quirk to this chipset and the
resume started working. Reloading the xhci_hcd module had been the temporary
workaround.Signed-off-by: Sarah Sharp
Reported-by: Don Zickus
Tested-by: Prarit Bhargava
Signed-off-by: Greg Kroah-Hartman -
commit 961794a00eab03f4344b7d5e825e8e789e55da87 upstream.
New Intuos series models added a hardware switch to turn touch
data on/off. The state of the switch is reported periodically
from the tablet. To report the state the driver will emit SW_MUTE_DEVICE
events.Reviewed_by: Chris Bagwell
Acked-by: Peter Hutterer
Tested-by: Jason Gerecke
Signed-off-by: Ping Cheng
Signed-off-by: Dmitry Torokhov
Cc: Josh Boyer
Signed-off-by: Greg Kroah-Hartman -
commit b5fd2a3e92ca5c8c1f3c20d31ac5daed3ec4d604 upstream.
Two tablets in this series support both pen and touch. One (Intuos S)
only supports pen. This patch also updates the driver to process wireless
devices that do not support touch interface.Tested-by: Jason Gerecke
Reviewed-by: Chris Bagwell
Signed-off-by: Ping Cheng
Signed-off-by: Dmitry Torokhov
Cc: Josh Boyer
Signed-off-by: Greg Kroah-Hartman -
commit 1d0d6df02750b4a6f466768cbfbf860e24f4c8d4 upstream.
Old single touch Tablet PCs do not have touch_max set at
wacom_features. Since touch device at lease supports one
finger, assign touch_max to 1 when touch usage is defined
in its HID Descriptor and touch_max is not pre-defined.Tested-by: Jason Gerecke
Signed-off-by: Ping Cheng
Reviewed-by: Chris Bagwell
Signed-off-by: Dmitry Torokhov
Cc: Josh Boyer
Signed-off-by: Greg Kroah-Hartman -
commit 26a865f4aa8e66a6d94958de7656f7f1b03c6c56 upstream.
After free_loaded_vmcs executes, the "loaded_vmcs" structure
is kfreed, and now vmx->loaded_vmcs points to a kfreed area.
Subsequent free_loaded_vmcs then attempts to manipulate
vmx->loaded_vmcs.Switch the order to avoid the problem.
https://bugzilla.redhat.com/show_bug.cgi?id=1047892
Reviewed-by: Jan Kiszka
Signed-off-by: Marcelo Tosatti
Cc: Josh Boyer
Signed-off-by: Greg Kroah-Hartman -
commit 37f6a4e237303549c8676dfe1fd1991ceab512eb upstream.
Rom Freiman notes other code paths vulnerable to
bug fixed by 989c6b34f6a9480e397b.Signed-off-by: Marcelo Tosatti
Cc: Josh Boyer
Signed-off-by: Greg Kroah-Hartman -
commit 989c6b34f6a9480e397b170cc62237e89bf4fdb9 upstream.
It is possible for __direct_map to be called on invalid root_hpa
(-1), two examples:1) try_async_pf -> can_do_async_pf
-> vmx_interrupt_allowed -> nested_vmx_vmexit
2) vmx_handle_exit -> vmx_interrupt_allowed -> nested_vmx_vmexitThen to load_vmcs12_host_state and kvm_mmu_reset_context.
Check for this possibility, let fault exception be regenerated.
BZ: https://bugzilla.redhat.com/show_bug.cgi?id=924916
Signed-off-by: Marcelo Tosatti
Signed-off-by: Paolo Bonzini
Cc: Josh Boyer
Signed-off-by: Greg Kroah-Hartman -
commit c15bdfd5b9831e4cab8cfc118243956e267dd30e upstream.
The current assumption in the elantech driver that hw version 3 touchpads
are never clickpads and hw version 4 touchpads are always clickpads is
wrong.There are several bug reports for this, ie:
https://bugzilla.redhat.com/show_bug.cgi?id=1030802
http://superuser.com/questions/619582/right-elantech-touchpad-button-not-working-in-linuxI've spend a couple of hours wading through various bugzillas, launchpads
and forum posts to create a list of fw-versions and capabilities for
different laptop models to find a good method to differentiate between
clickpads and versions with separate hardware buttons.Which shows that a device being a clickpad is reliable indicated by bit 12
being set in the fw_version. I've included the gathered list inside the
driver, so that we've this info at hand if we need to revisit this later.Signed-off-by: Hans de Goede
Reviewed-by: Benjamin Tissoires
Signed-off-by: Dmitry Torokhov
Cc: Josh Boyer
Signed-off-by: Greg Kroah-Hartman -
commit c1d867a54d426b45da017fbe8e585f8a3064ce8d upstream.
Distribution kernels might want to build in support for /proc/device-tree
for kernels that might end up running on hardware that doesn't support
openfirmware. This results in an empty /proc/device-tree existing.
Remove it if the OFW root node doesn't exist.This situation actually confuses grub2, resulting in install failures.
grub2 sees the /proc/device-tree and picks the wrong install target cf.
http://bzr.savannah.gnu.org/lh/grub/trunk/grub/annotate/4300/util/grub-install.in#L311
grub should be more robust, but still, leaving an empty proc dir seems
pointless.Addresses https://bugzilla.redhat.com/show_bug.cgi?id=818378.
Signed-off-by: Dave Jones
Cc: Al Viro
Cc: Paul Mackerras
Cc: Josh Boyer
Cc: Benjamin Herrenschmidt
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit af87d2fe95444d107e0c0cf0ba7e20e6716a7bfd upstream.
As Ben suggested, the patch prints PHB diag-data with multiple
fields in one line and omits the line if the fields of that
line are all zero.With the patch applied, the PHB3 diag-data dump looks like:
PHB3 PHB#3 Diag-data (Version: 1)
brdgCtl: 00000002
RootSts: 0000000f 00400000 b0830008 00100147 00002000
nFir: 0000000000000000 0030006e00000000 0000000000000000
PhbSts: 0000001c00000000 0000000000000000
Lem: 0000000000100000 42498e327f502eae 0000000000000000
InAErr: 8000000000000000 8000000000000000 0402030000000000 0000000000000000
PE[ 8] A/B: 8480002b00000000 8000000000000000[ The current diag data is so big that it overflows the printk
buffer pretty quickly in cases when we get a handful of errors
at once which can happen. --BenH
]Signed-off-by: Gavin Shan
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Greg Kroah-Hartman -
commit 947166043732b69878123bf31f51933ad0316080 upstream.
The PHB diag-data is important to help locating the root cause for
EEH errors such as frozen PE or fenced PHB. However, the EEH core
enables IO path by clearing part of HW registers before collecting
this data causing it to be corrupted.This patch fixes this by dumping the PHB diag-data immediately when
frozen/fenced state on PE or PHB is detected for the first time in
eeh_ops::get_state() or next_error() backend.Signed-off-by: Gavin Shan
CC:
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Greg Kroah-Hartman -
commit 7e4e7867b1e551b7b8f326da3604c47332972bc6 upstream.
For one PCI error relevant OPAL event, we possibly have multiple
EEH errors for that. For example, multiple frozen PEs detected on
different PHBs. Unfortunately, we didn't cover the case. The patch
enumarates the return value from eeh_ops::next_error() and change
eeh_handle_special_event() and eeh_ops::next_error() to handle all
existing EEH errors.As Ben pointed out, we needn't list_for_each_entry_safe() since we
are not deleting any PHB from the hose_list and the EEH serialized
lock should be held while purging EEH events. The patch covers those
suggestions as well.Signed-off-by: Gavin Shan
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Greg Kroah-Hartman -
commit 93aef2a789778e7ec787179fc9b34ca4885a5ef3 upstream.
Prior to the completion of PCI enumeration, we actively detects
EEH errors on PCI config cycles and dump PHB diag-data if necessary.
The EEH backend also dumps PHB diag-data in case of frozen PE or
fenced PHB. However, we are using different functions to dump the
PHB diag-data for those 2 cases.The patch merges the functions for dumping PHB diag-data to one so
that we can avoid duplicate code. Also, we never dump PHB3 diag-data
during PCI config cycles with frozen PE. The patch fixes it as well.Signed-off-by: Gavin Shan
Signed-off-by: Benjamin Herrenschmidt
Signed-off-by: Greg Kroah-Hartman -
commit 66fda75f47dc583f1c187556e9a2c082dd64f8c6 upstream.
There are many places where ops->disable is called directly. Instead we
should use _regulator_do_disable() which also handles gpio regulators.To be able to use the wrapper function from _regulator_force_disable(),
I moved the _notifier_call_chain() call from _regulator_do_disable() to
_regulator_disable(). This way, _regulator_force_disable() can use
different flags for _notifier_call_chain() without calling it twice.Signed-off-by: Markus Pargmann
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 608cfbe4abaf76e9d732efd7ed1cfa3998163d91 upstream.
The call to clamp_t() first truncates the variable signed 8 bit and as a
result, the actual clamp is a no-op.Fixes: 0d78156eef1d ('p54: improve site survey')
Signed-off-by: Dan Carpenter
Signed-off-by: John W. Linville
Signed-off-by: Greg Kroah-Hartman -
commit 63238f2cc5518e1c45a3418fc0ac0f560dafe7ef upstream.
The following build error is seen if CONFIG_32BIT is undefined,
CONFIG_64BIT is defined, and CONFIG_MIPS32_O32 is undefined.asm/syscall.h: In function 'mips_get_syscall_arg':
arch/mips/include/asm/syscall.h:32:16: error: unused variable 'usp' [-Werror=unused-variable]
cc1: all warnings being treated as errorsFixes: c0ff3c53d4f9 ('MIPS: Enable HAVE_ARCH_TRACEHOOK')
Signed-off-by: Guenter Roeck
Acked-by: David Daney
Signed-off-by: John Crispin
Patchwork: http://patchwork.linux-mips.org/patch/6160/
Signed-off-by: Greg Kroah-Hartman -
commit f8ce239dfc7ba9add41d9ecdc5e7810738f839fa upstream.
builddeb generates a control file that says the linux-headers package
can only be built for the build system primary architecture. This
breaks cross-building configurations. We should use $debarch for this
instead.Since $debarch is not yet set when generating the control file, set
Architecture: any and use control file variables to fill in the
description.Fixes: cd8d60a20a45 ('kbuild: create linux-headers package in deb-pkg')
Reported-and-tested-by: "Niew, Sh."
Signed-off-by: Ben Hutchings
Signed-off-by: Michal Marek
Signed-off-by: Greg Kroah-Hartman -
commit c5e318f67eebbad491615a752c51dbfde7dc3d78 upstream.
These commands will mysteriously fail:
$ make ARCH=arm versatile_defconfig
[...]
$ make ARCH=arm deb-pkg
[...]
make[1]: *** [deb-pkg] Error 1
make: *** [deb-pkg] Error 2The Debian architecture selection for these kernel architectures does
'grep FOO=y $KCONFIG_CONFIG && echo bar', and after 'set -e' this
aborts the script if grep does not find the given config symbol.Fixes: 10f26fa64200 ('build, deb-pkg: select userland architecture based on UTS_MACHINE')
Signed-off-by: Ben Hutchings
Signed-off-by: Michal Marek
Signed-off-by: Greg Kroah-Hartman -
commit f428ebd184c82a7914b2aa7e9f868918aaf7ea78 upstream.
Someone got the load and store barriers mixed up for AAAAARGH64. Turn
them the right side up.Reported-by: Will Deacon
Signed-off-by: Peter Zijlstra
Fixes: a94d342b9cb0 ("tools/perf: Add required memory barriers")
Cc: Ingo Molnar
Cc: Will Deacon
Link: http://lkml.kernel.org/r/20140124154002.GF31570@twins.programming.kicks-ass.net
Signed-off-by: Arnaldo Carvalho de Melo
Signed-off-by: Greg Kroah-Hartman -
commit e83b366487b5582274374f8226e489cb214ae5a6 upstream.
We must use a 64-bit for this, otherwise overflowed bits get lost, and
that can result in a lower than intended value set.Fixes: 8e0cb8a1f6ac ("ARM: 7797/1: mmc: Use dma_max_pfn(dev) helper for bounce_limit calculations")
Fixes: 7d35496dd982 ("ARM: 7796/1: scsi: Use dma_max_pfn(dev) helper for bounce_limit calculations")
Tested-Acked-by: Santosh Shilimkar
Reviewed-by: Ulf Hansson
Signed-off-by: Russell King
Signed-off-by: Greg Kroah-Hartman -
commit e4178d809fdaee32a56833fff1f5056c99e90a1a upstream.
This is not a buffer overflow in the traditional sense: we don't
overflow any *kernel* buffers, but we do mis-count the amount of data we
copy back to user space for the SYSLOG_ACTION_READ_ALL case.In particular, if the user buffer is too small to hold everything, and
*if* there is a continuation line at just the right place, we can end up
giving the user more data than he asked for.The reason is that we first count up the number of bytes all the log
records contains, then we walk the records again until we've skipped the
records at the beginning that won't fit, and then we walk the rest of
the records and copy them to the user space buffer.And in between that "skip the initial records that won't fit" and the
"copy the records that *will* fit to user space", we reset the 'prev'
variable that contained the record information for the last record not
copied. That meant that when we started copying to user space, we now
had a different character count than what we had originally calculated
in the first record walk-through.The fix is to simply not clear the 'prev' flags value (in both cases
where we had the same logic: syslog_print_all and kmsg_dump_get_buffer:
the latter is used for pstore-like dumping)Reported-and-tested-by: Debabrata Banerjee
Acked-by: Kay Sievers
Cc: Jeff Mahoney
Signed-off-by: Linus Torvalds
Cc: Josh Hunt
Signed-off-by: Greg Kroah-Hartman -
commit fdfaf64e75397567257e1051931f9a3377360665 upstream.
Commit a998d4342337 claimed to introduce negative offset support to x86 jit,
but it couldn't be working, since at the time of the execution
of LD+ABS or LD+IND instructions via call into
bpf_internal_load_pointer_neg_helper() the %edx (3rd argument of this func)
had junk value instead of access size in bytes (1 or 2 or 4).Store size into %edx instead of %ecx (what original commit intended to do)
Fixes: a998d4342337 ("bpf jit: Let the x86 jit handle negative offsets")
Signed-off-by: Alexei Starovoitov
Cc: Jan Seiffert
Cc: Eric Dumazet
Acked-by: Eric Dumazet
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit e9776d0f4adee8877145672f6416b06b57f2dc27 upstream.
In gss_alloc_msg(), if the call to gss_encode_v1_msg() fails, we
want to release the reference to the pipe_version that was obtained
earlier in the function.Fixes: 9d3a2260f0f4b (SUNRPC: Fix buffer overflow checking in...)
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit 4c235cb9e35407bdb4a2debeef4dc8721e8f91f2 upstream.
Commit 65939301acdb (arm: set initrd_start/initrd_end for fdt scan)
caused the FDT initrd_start and initrd_end to override the
phys_initrd_start and phys_initrd_size set by the initrd= kernel
parameter. With this patch initrd_start and initrd_end will be
overridden if phys_initrd_start and phys_initrd_size are set by the
kernel initrd= parameter.Fixes: 65939301acdb (arm: set initrd_start/initrd_end for fdt scan)
Signed-off-by: Ben Peddell
Acked-by: Jason Cooper
Signed-off-by: Russell King
Signed-off-by: Greg Kroah-Hartman -
commit d9317aea16ecec7694271ef11fb7791a0f0d9cc5 upstream.
As part of a workaround for a hardware erratum in the SFC9100 family
(SF bug 35388), the TX_DESC_UPD_DWORD register address is also used
for communicating with the event block, and only descriptor pointer
values < 2048 are valid.If the TX DMA ring size is increased to 4096 descriptors (which the
firmware still allows) then we may write a descriptor pointer
value >= 2048, which has entirely different and undesirable effects!Limit the TX DMA ring size correctly when this workaround is in
effect.Fixes: 8127d661e77f ('sfc: Add support for Solarflare SFC9100 family')
Signed-off-by: Ben Hutchings
Signed-off-by: Shradha Shah
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit 177c53d943368fc97644ebc0a250dc8e2d124250 upstream.
We must use smp_call_function_single(.wait=1) for the
irq_cpu_stop_queue_work() to ensure the queueing is actually done under
stop_cpus_lock. Without this we could have dropped the lock by the time
we do the queueing and get the race we tried to fix.Fixes: 7053ea1a34fa ("stop_machine: Fix race between stop_two_cpus() and stop_cpus()")
Signed-off-by: Peter Zijlstra
Cc: Prarit Bhargava
Cc: Rik van Riel
Cc: Mel Gorman
Cc: Christoph Hellwig
Cc: Andrew Morton
Link: http://lkml.kernel.org/r/20140228123905.GK3104@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar
Signed-off-by: Greg Kroah-Hartman -
commit e126a646f77fdd66978785cb0a3a5e46b07aee2e upstream.
The REVISION_ID register is not currently marked readable. snd_soc_read()
refuses to read the register, and hence probe() fails.Fixes: d4807ad2c4c0 ("regmap: Check readable regs in _regmap_read")
[exposed the bug, by checking for readability]
Fixes: 685e42154dcf ("ASoC: Replace max98090 Device Driver")
[left out this register from the readable list]
Signed-off-by: Stephen Warren
Signed-off-by: Mark Brown
Signed-off-by: Greg Kroah-Hartman -
commit 9a1ea2dbff11547a8e664f143c1ffefc586a577a upstream.
With the current full handling, there is a race between osds and
clients getting the first map marked full. If the osd wins, it will
return -ENOSPC to any writes, but the client may already have writes
in flight. This results in the client getting the error and
propagating it up the stack. For rbd, the block layer turns this into
EIO, which can cause corruption in filesystems above it.To avoid this race, osds are being changed to drop writes that came
from clients with an osdmap older than the last osdmap marked full.
In order for this to work, clients must resend all writes after they
encounter a full -> not full transition in the osdmap. osds will wait
for an updated map instead of processing a request from a client with
a newer map, so resent writes will not be dropped by the osd unless
there is another not full -> full transition.This approach requires both osds and clients to be fixed to avoid the
race. Old clients talking to osds with this fix may hang instead of
returning EIO and potentially corrupting an fs. New clients talking to
old osds have the same behavior as before if they encounter this race.Fixes: http://tracker.ceph.com/issues/6938
Reviewed-by: Sage Weil
Signed-off-by: Josh Durgin
Signed-off-by: Greg Kroah-Hartman -
commit d29adb34a94715174c88ca93e8aba955850c9bde upstream.
The PAUSEWR and PAUSERD flags are meant to stop the cluster from
processing writes and reads, respectively. The FULL flag is set when
the cluster determines that it is out of space, and will no longer
process writes. PAUSEWR and PAUSERD are purely client-side settings
already implemented in userspace clients. The osd does nothing special
with these flags.When the FULL flag is set, however, the osd responds to all writes
with -ENOSPC. For cephfs, this makes sense, but for rbd the block
layer translates this into EIO. If a cluster goes from full to
non-full quickly, a filesystem on top of rbd will not behave well,
since some writes succeed while others get EIO.Fix this by blocking any writes when the FULL flag is set in the osd
client. This is the same strategy used by userspace, so apply it by
default. A follow-on patch makes this configurable.__map_request() is called to re-target osd requests in case the
available osds changed. Add a paused field to a ceph_osd_request, and
set it whenever an appropriate osd map flag is set. Avoid queueing
paused requests in __map_request(), but force them to be resent if
they become unpaused.Also subscribe to the next osd map from the monitor if any of these
flags are set, so paused requests can be unblocked as soon as
possible.Fixes: http://tracker.ceph.com/issues/6079
Reviewed-by: Sage Weil
Signed-off-by: Josh Durgin
Signed-off-by: Greg Kroah-Hartman -
commit e351bf25fa373a3de0be2141b962c5c3c27006a2 upstream.
It upsets static checkers when we don't check for allocation failure. I
moved the memset() of "tv" earlier so we don't use uninitialized data on
error.
Fixes: 1d212cf0c2d8 ('[media] cx18: struct i2c_client is too big for stack')Signed-off-by: Dan Carpenter
Acked-by: Andy Walls
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 324ed533bf0b23c309b805272c4ffcc5d51493a6 upstream.
We recently introduced some new error paths but the unlocks are missing.
Fixes: 0065a79a8698 ('[media] dw2102: Don't use dynamic static allocation')Signed-off-by: Dan Carpenter
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 1cdbcc5db4e6d51ce9bb1313195167cada9aa6e9 upstream.
We recently introduced some new error paths which are missing their
unlocks.
Fixes: 64f7ef8afbf8 ('[media] cxusb: Don't use dynamic static allocation')Signed-off-by: Dan Carpenter
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 292f503cade2b1d966239ef56a851e6897d1ba92 upstream.
We need to use the same net namespace that was used to resolve
the hostname and sockaddr arguments.Fixes: 32e62b7c3ef09 (NFS: Add nfs4_update_server)
Cc: Chuck Lever
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit 33b7107f59a61236d94ecd6b45e20283cd5abcc8 upstream.
In commit 6892b41d9701283085b655c6086fb57a5d63fa47
Author: Lad, Prabhakar
Date: Tue Jun 25 21:24:51 2013 +0530
net: davinci: emac: Convert to devm_* apithe call of request_irq is replaced by devm_request_irq and the call
of free_irq is removed. But since interrupts are requested in
emac_dev_open, doing ifconfig up/down on the board requests the
interrupts again each time, causing devm_request_irq to fail. The
interface is dead until the device is rebooted.This patch reverts said commit partially: It changes the driver back
to use request_irq instead of devm_request_irq, puts free_irq back in
place, but keeps the remaining changes of the original patch.Reported-by: Jon Ringle
Signed-off-by: Christian Riesch
Cc: Lad, Prabhakar
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman -
commit a2fb4d782c61f77480e586578eeb4dfd27d134ea upstream.
STI console is used on parisc and m68k HP machines. This patch partly reverts
my previous commit and as such restores the fonts for the m68k machines.Signed-off-by: Helge Deller
Signed-off-by: Greg Kroah-Hartman