07 Mar, 2015
40 commits
-
commit c99197902da284b4b723451c1471c45b18537cde upstream.
The usb_hcd_unlink_urb() routine in hcd.c contains two possible
use-after-free errors. The dev_dbg() statement at the end of the
routine dereferences urb and urb->dev even though both structures may
have been deallocated.This patch fixes the problem by storing urb->dev in a local variable
(avoiding the dereference of urb) and moving the dev_dbg() up before
the usb_put_dev() call.Signed-off-by: Alan Stern
Reported-by: Joe Lawrence
Tested-by: Joe Lawrence
Signed-off-by: Greg Kroah-Hartman
Signed-off-by: Greg Kroah-Hartman -
commit a6f0331236fa75afba14bbcf6668d42cebb55c43 upstream.
Added the USB serial console device ID for Siemens Ruggedcom devices
which have a USB port for their serial console.Signed-off-by: Len Sorensen
Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman -
commit 6fbb9bdf0f3fbe23aeff806489791aa876adaffb upstream.
-EDEFER error wasn't handle properly by atmel_serial_probe().
As an example, when atmel_serial_probe() is called for the first time, we pass
the test_and_set_bit() test to check whether the port has already been
initalized. Then we call atmel_init_port(), which may return -EDEFER, possibly
returned before by clk_get(). Consequently atmel_serial_probe() used to return
this error code WITHOUT clearing the port bit in the "atmel_ports_in_use" mask.
When atmel_serial_probe() was called for the second time, it used to fail on
the test_and_set_bit() function then returning -EBUSY.When atmel_serial_probe() fails, this patch make it clear the port bit in the
"atmel_ports_in_use" mask, if needed, before returning the error code.Signed-off-by: Cyrille Pitchen
Acked-by: Nicolas Ferre
Signed-off-by: Greg Kroah-Hartman -
commit 37480a05685ed5b8e1b9bf5e5c53b5810258b149 upstream.
Commit 26df6d13406d1a5 ("tty: Add EXTPROC support for LINEMODE")
allows a process which has opened a pty master to send _any_ signal
to the process group of the pty slave. Although potentially
exploitable by a malicious program running a setuid program on
a pty slave, it's unknown if this exploit currently exists.Limit to signals actually used.
Cc: Theodore Ts'o
Cc: Howard Chu
Cc: One Thousand Gnomes
Cc: Jiri Slaby
Signed-off-by: Peter Hurley
Signed-off-by: Greg Kroah-Hartman -
commit 91117a20245b59f70b563523edbf998a62fc6383 upstream.
The 'pfn' returned by axonram was completely bogus, and has been since
2008.Signed-off-by: Matthew Wilcox
Reviewed-by: Jan Kara
Reviewed-by: Mathieu Desnoyers
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit c6ce194325cef342313e3d27620411ce90a89c50 upstream.
Hi,
If you can manage to submit an async write as the first async I/O from
the context of a process with realtime scheduling priority, then a
cfq_queue is allocated, but filed into the wrong async_cfqq bucket. It
ends up in the best effort array, but actually has realtime I/O
scheduling priority set in cfqq->ioprio.The reason is that cfq_get_queue assumes the default scheduling class and
priority when there is no information present (i.e. when the async cfqq
is created):static struct cfq_queue *
cfq_get_queue(struct cfq_data *cfqd, bool is_sync, struct cfq_io_cq *cic,
struct bio *bio, gfp_t gfp_mask)
{
const int ioprio_class = IOPRIO_PRIO_CLASS(cic->ioprio);
const int ioprio = IOPRIO_PRIO_DATA(cic->ioprio);cic->ioprio starts out as 0, which is "invalid". So, class of 0
(IOPRIO_CLASS_NONE) is passed to cfq_async_queue_prio like so:async_cfqq = cfq_async_queue_prio(cfqd, ioprio_class, ioprio);
static struct cfq_queue **
cfq_async_queue_prio(struct cfq_data *cfqd, int ioprio_class, int ioprio)
{
switch (ioprio_class) {
case IOPRIO_CLASS_RT:
return &cfqd->async_cfqq[0][ioprio];
case IOPRIO_CLASS_NONE:
ioprio = IOPRIO_NORM;
/* fall through */
case IOPRIO_CLASS_BE:
return &cfqd->async_cfqq[1][ioprio];
case IOPRIO_CLASS_IDLE:
return &cfqd->async_idle_cfqq;
default:
BUG();
}
}Here, instead of returning a class mapped from the process' scheduling
priority, we get back the bucket associated with IOPRIO_CLASS_BE.Now, there is no queue allocated there yet, so we create it:
cfqq = cfq_find_alloc_queue(cfqd, is_sync, cic, bio, gfp_mask);
That function ends up doing this:
cfq_init_cfqq(cfqd, cfqq, current->pid, is_sync);
cfq_init_prio_data(cfqq, cic);cfq_init_cfqq marks the priority as having changed. Then, cfq_init_prio
data does this:ioprio_class = IOPRIO_PRIO_CLASS(cic->ioprio);
switch (ioprio_class) {
default:
printk(KERN_ERR "cfq: bad prio %x\n", ioprio_class);
case IOPRIO_CLASS_NONE:
/*
* no prio set, inherit CPU scheduling settings
*/
cfqq->ioprio = task_nice_ioprio(tsk);
cfqq->ioprio_class = task_nice_ioclass(tsk);
break;So we basically have two code paths that treat IOPRIO_CLASS_NONE
differently, which results in an RT async cfqq filed into a best effort
bucket.Attached is a patch which fixes the problem. I'm not sure how to make
it cleaner. Suggestions would be welcome.Signed-off-by: Jeff Moyer
Tested-by: Hidehiro Kawai
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit 69abaffec7d47a083739b79e3066cb3730eba72e upstream.
Cfq_lookup_create_cfqg() allocates struct blkcg_gq using GFP_ATOMIC.
In cfq_find_alloc_queue() possible allocation failure is not handled.
As a result kernel oopses on NULL pointer dereference when
cfq_link_cfqq_cfqg() calls cfqg_get() for NULL pointer.Bug was introduced in v3.5 in commit cd1604fab4f9 ("blkcg: factor
out blkio_group creation"). Prior to that commit cfq group lookup
had returned pointer to root group as fallback.This patch handles this error using existing fallback oom_cfqq.
Signed-off-by: Konstantin Khlebnikov
Acked-by: Tejun Heo
Acked-by: Vivek Goyal
Fixes: cd1604fab4f9 ("blkcg: factor out blkio_group creation")
Signed-off-by: Jens Axboe
Signed-off-by: Greg Kroah-Hartman -
commit 3fd7b60f2c7418239d586e359e0c6d8503e10646 upstream.
This patch drops legacy active_ts_list usage within iscsi_target_tq.c
code. It was originally used to track the active thread sets during
iscsi-target shutdown, and is no longer used by modern upstream code.Two people have reported list corruption using traditional iscsi-target
and iser-target with the following backtrace, that appears to be related
to iscsi_thread_set->ts_list being used across both active_ts_list and
inactive_ts_list.[ 60.782534] ------------[ cut here ]------------
[ 60.782543] WARNING: CPU: 0 PID: 9430 at lib/list_debug.c:53 __list_del_entry+0x63/0xd0()
[ 60.782545] list_del corruption, ffff88045b00d180->next is LIST_POISON1 (dead000000100100)
[ 60.782546] Modules linked in: ib_srpt tcm_qla2xxx qla2xxx tcm_loop tcm_fc libfc scsi_transport_fc scsi_tgt ib_isert rdma_cm iw_cm ib_addr iscsi_target_mod target_core_pscsi target_core_file target_core_iblock target_core_mod configfs ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 ipt_REJECT xt_CHECKSUM iptable_mangle iptable_filter ip_tables bridge stp llc autofs4 sunrpc ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables ipv6 ib_ipoib ib_cm ib_uverbs ib_umad mlx4_en mlx4_ib ib_sa ib_mad ib_core mlx4_core dm_mirror dm_region_hash dm_log dm_mod vhost_net macvtap macvlan vhost tun kvm_intel kvm uinput iTCO_wdt iTCO_vendor_support microcode serio_raw pcspkr sb_edac edac_core sg i2c_i801 lpc_ich mfd_core mtip32xx igb i2c_algo_bit i2c_core ptp pps_core ioatdma dca wmi ext3(F) jbd(F) mbcache(F) sd_mod(F) crc_t10dif(F) crct10dif_common(F) ahci(F) libahci(F) isci(F) libsas(F) scsi_transport_sas(F) [last unloaded: speedstep_lib]
[ 60.782597] CPU: 0 PID: 9430 Comm: iscsi_ttx Tainted: GF 3.12.19+ #2
[ 60.782598] Hardware name: Supermicro X9DRX+-F/X9DRX+-F, BIOS 3.00 07/09/2013
[ 60.782599] 0000000000000035 ffff88044de31d08 ffffffff81553ae7 0000000000000035
[ 60.782602] ffff88044de31d58 ffff88044de31d48 ffffffff8104d1cc 0000000000000002
[ 60.782605] ffff88045b00d180 ffff88045b00d0c0 ffff88045b00d0c0 ffff88044de31e58
[ 60.782607] Call Trace:
[ 60.782611] [] dump_stack+0x49/0x62
[ 60.782615] [] warn_slowpath_common+0x8c/0xc0
[ 60.782618] [] warn_slowpath_fmt+0x46/0x50
[ 60.782620] [] __list_del_entry+0x63/0xd0
[ 60.782622] [] list_del+0x11/0x40
[ 60.782630] [] iscsi_del_ts_from_active_list+0x29/0x50 [iscsi_target_mod]
[ 60.782635] [] iscsi_tx_thread_pre_handler+0xa1/0x180 [iscsi_target_mod]
[ 60.782642] [] iscsi_target_tx_thread+0x4e/0x220 [iscsi_target_mod]
[ 60.782647] [] ? iscsit_handle_snack+0x190/0x190 [iscsi_target_mod]
[ 60.782652] [] ? iscsit_handle_snack+0x190/0x190 [iscsi_target_mod]
[ 60.782655] [] kthread+0xce/0xe0
[ 60.782657] [] ? kthread_freezable_should_stop+0x70/0x70
[ 60.782660] [] ret_from_fork+0x7c/0xb0
[ 60.782662] [] ? kthread_freezable_should_stop+0x70/0x70
[ 60.782663] ---[ end trace 9662f4a661d33965 ]---Since this code is no longer used, go ahead and drop the problematic usage
all-together.Reported-by: Gavin Guo
Reported-by: Moussa Ba
Signed-off-by: Nicholas Bellinger
Signed-off-by: Greg Kroah-Hartman -
commit d8ba1f971497c19cf80da1ea5391a46a5f9fbd41 upstream.
If the call to decode_rc_list() fails due to a memory allocation error,
then we need to truncate the array size to ensure that we only call
kfree() on those pointer that were allocated.Reported-by: David Ramos
Fixes: 4aece6a19cf7f ("nfs41: cb_sequence xdr implementation")
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit eb71f8a5e33fa1066fb92f0111ab366a341e1f6c upstream.
The tpm_ibmvtpm module is affected by an unaligned access problem.
ibmvtpm_crq_get_version failed with rc=-4 during boot when vTPM is
enabled in Power partition, which supports both little endian and
big endian modes.We added little endian support to fix this problem:
1) added cpu_to_be64 calls to ensure BE data is sent from an LE OS.
2) added be16_to_cpu and be32_to_cpu calls to make sure data received
is in LE format on a LE OS.Signed-off-by: Hon Ching(Vicky) Lo
Signed-off-by: Joy Latten
[phuewe: manually applied the patch :( ]
Reviewed-by: Ashley Lai
Signed-off-by: Peter Huewe
Signed-off-by: Greg Kroah-Hartman -
commit 1ba3b0b6f218072afe8372d12f1b6bf26a26008e upstream.
When sending data in tpm_stm_i2c_send, each loop iteration send buf.
Send buf + i instead as the goal of this for loop is to send a number
of byte from buf that fit in burstcnt. Once those byte are sent, we are
supposed to send the next ones.The driver was working because the burstcount value returns always the maximum size for a TPM
command or response. (0x800 for a command and 0x400 for a response).Reviewed-by: Jason Gunthorpe
Signed-off-by: Christophe Ricard
Signed-off-by: Peter Huewe
Signed-off-by: Greg Kroah-Hartman -
commit 84eb186bc37c0900b53077ca21cf6dd15823a232 upstream.
There was an oops in tpm_ibmvtpm_get_desired_dma, which caused
kernel panic during boot when vTPM is enabled in Power partition
configured in AMS mode.vio_bus_probe calls vio_cmo_bus_probe which calls
tpm_ibmvtpm_get_desired_dma to get the size needed for DMA allocation.
The problem is, vio_cmo_bus_probe is called before calling probe, which
for vtpm is tpm_ibmvtpm_probe and it's this function that initializes
and sets up vtpm's CRQ and gets required data values. Therefore,
since this has not yet been done, NULL is returned in attempt to get
the size for DMA allocation.We added a NULL check. In addition, a default buffer size will
be set when NULL is returned.Signed-off-by: Hon Ching (Vicky) Lo
Signed-off-by: Peter Huewe
Signed-off-by: Greg Kroah-Hartman -
commit bb95cd34ba4c9467114acc78eeddd53ab1c10085 upstream.
Currently these driver are missing a check on the return value of devm_kzalloc,
which would cause a NULL pointer dereference in a OOM situation.This patch adds a missing check for tpm_i2c_atmel.c and tpm_i2c_nuvoton.c
Signed-off-by: Kiran Padwal
Reviewed-By: Jason Gunthorpe
Signed-off-by: Peter Huewe
Signed-off-by: Greg Kroah-Hartman -
commit 398a1e71dc827b994b7f2f56c7c2186fea7f8d75 upstream.
Add newly registered TPMs to the tail of the list, not the beginning, so that
things that are specifying TPM_ANY_NUM don't find that the device they're
using has inadvertently changed. Adding a second device would break IMA, for
instance.Signed-off-by: David Howells
Reviewed-by: Jason Gunthorpe
Signed-off-by: Peter Huewe
Signed-off-by: Greg Kroah-Hartman -
commit 448e9c55c12d6bd4fa90a7e31d802e045666d7c8 upstream.
Some machines, such as the Acer C720 and Toshiba CB35, have TPMs that do
not send IRQs while also having an ACPI TPM entry indicating that they
will be sent. These machines freeze on resume while the tpm_tis module
waits for an IRQ, eventually timing out.When in interrupt mode, the tpm_tis module should receive an IRQ during
module init. Fall back to polling mode if none is received when expected.Signed-off-by: Scot Doyle
Tested-by: Michael Mullin
Reviewed-by: Jason Gunthorpe
[phuewe: minor checkpatch fixed]
Signed-off-by: Peter Huewe
Signed-off-by: Greg Kroah-Hartman -
commit 67fd14b3eca63b14429350e9eadc5fab709a8821 upstream.
Fixes: http://bugs.elinux.org/issues/127
the bb.org community was seeing random reboots before this change.
Signed-off-by: Robert Nelson
Reviewed-by: Felipe Balbi
Acked-by: Felipe Balbi
Signed-off-by: Tony Lindgren
Signed-off-by: Greg Kroah-Hartman -
commit de47699d005996b41cea590c6098078ac12058be upstream.
Commit 58ecb23f64ee ("ARM: tegra: add missing unit addresses to DT") added
unit address and changed reg base for GR3D and DSI host1x modules, but these
addresses belongs to GR2D and TVO modules respectively. Fix it by changing
modules unit and reg base addresses to proper ones.Signed-off-by: Dmitry Osipenko
Fixes: 58ecb23f64ee (ARM: tegra: add missing unit addresses to DT)
Reviewed-by: Alexandre Courbot
Signed-off-by: Thierry Reding
Signed-off-by: Greg Kroah-Hartman -
commit 1c7e36bfc3e2fb2df5e2d1989a4b6fb9055a0f9b upstream.
With commit '7dedd34: ARM: OMAP2+: hwmod: Fix a crash in _setup_reset()
with DEBUG_LL' we moved from parsing cmdline to identify uart used
for earlycon to using the requsite hwmod CONFIG_DEBUG_OMAPxUARTy FLAGS.On DRA7 UART3 hwmod doesn't have this flag enabled, and atleast on
BeagleBoard-X15, where we use UART3 for console, boot fails with
DEBUG_LL enabled. Enable DEBUG_OMAP4UART3_FLAGS for UART3 hwmod.For using DEBUG_LL, enable CONFIG_DEBUG_OMAP4UART3 in menuconfig.
Fixes: 90020c7b2c5e ("ARM: OMAP: DRA7: hwmod: Create initial DRA7XX SoC data")
Reviewed-by: Felipe Balbi
Acked-by: Felipe Balbi
Signed-off-by: Lokesh Vutla
Signed-off-by: Paul Walmsley
Signed-off-by: Greg Kroah-Hartman -
commit e461894dc2ce7778ccde1c3483c9b15a85a7fc5f upstream.
StrongARM core uses RCSR SMR bit to tell to bootloader that it was reset
by entering the sleep mode. After we have resumed, there is little point
in having that bit enabled. Moreover, if this bit is set before reboot,
the bootloader can become confused. Thus clear the SMR bit on resume
just before clearing the scratchpad (resume address) register.Signed-off-by: Dmitry Eremin-Solenikov
Signed-off-by: Russell King
Signed-off-by: Greg Kroah-Hartman -
commit 7215853e985a4bef1a6c14e00e89dfec84f1e457 upstream.
Commit 6edb2a8a385f0cdef51dae37ff23e74d76d8a6ce introduced
an array map_pages that contains the addresses returned by
kmap_atomic. However, when unmapping those pages, map_pages[0]
is unmapped before map_pages[1], breaking the nesting requirement
as specified in the documentation for kmap_atomic/kunmap_atomic.This was caught by the highmem debug code present in kunmap_atomic.
Fix the loop to do the unmapping properly.Link: http://lkml.kernel.org/r/1418871056-6614-1-git-send-email-markivx@codeaurora.org
Reviewed-by: Stephen Boyd
Reported-by: Lime Yang
Signed-off-by: Vikram Mulukutla
Signed-off-by: Steven Rostedt
Signed-off-by: Greg Kroah-Hartman -
commit cbef8478bee55775ac312a574aad48af7bb9cf9f upstream.
Migrating hugepages and hwpoisoned hugepages are considered as non-present
hugepages, and they are referenced via migration entries and hwpoison
entries in their page table slots.This behavior causes race condition because pmd_huge() doesn't tell
non-huge pages from migrating/hwpoisoned hugepages. follow_page_mask() is
one example where the kernel would call follow_page_pte() for such
hugepage while this function is supposed to handle only normal pages.To avoid this, this patch makes pmd_huge() return true when pmd_none() is
true *and* pmd_present() is false. We don't have to worry about mixing up
non-present pmd entry with normal pmd (pointing to leaf level pte entry)
because pmd_present() is true in normal pmd.The same race condition could happen in (x86-specific) gup_pmd_range(),
where this patch simply adds pmd_present() check instead of pmd_huge().
This is because gup_pmd_range() is fast path. If we have non-present
hugepage in this function, we will go into gup_huge_pmd(), then return 0
at flag mask check, and finally fall back to the slow path.Fixes: 290408d4a2 ("hugetlb: hugepage migration core")
Signed-off-by: Naoya Horiguchi
Cc: Hugh Dickins
Cc: James Hogan
Cc: David Rientjes
Cc: Mel Gorman
Cc: Johannes Weiner
Cc: Michal Hocko
Cc: Rik van Riel
Cc: Andrea Arcangeli
Cc: Luiz Capitulino
Cc: Nishanth Aravamudan
Cc: Lee Schermerhorn
Cc: Steve Capper
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
Signed-off-by: Greg Kroah-Hartman -
commit 044f0f03eca0110e1835b2ea038a484b93950328 upstream.
When about to run the guest, deliver guest interrupts after disabling
host interrupts. This should prevent an hrtimer interrupt from being
handled after delivering guest interrupts, and therefore not delivering
the guest timer interrupt until after the next guest exit.Signed-off-by: James Hogan
Cc: Paolo Bonzini
Cc: Gleb Natapov
Cc: kvm@vger.kernel.org
Cc: Ralf Baechle
Cc: linux-mips@linux-mips.org
Cc: Sanjay Lal
Signed-off-by: Paolo Bonzini
Signed-off-by: Greg Kroah-Hartman -
commit 6ffa30d3f734d4f6b478081dfc09592021028f90 upstream.
Bruce reported seeing this warning pop when mounting using v4.1:
------------[ cut here ]------------
WARNING: CPU: 1 PID: 1121 at kernel/sched/core.c:7300 __might_sleep+0xbd/0xd0()
do not call blocking ops when !TASK_RUNNING; state=1 set at [] prepare_to_wait+0x2f/0x90
Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace sunrpc fscache ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw snd_hda_codec_generic snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_pcm snd_timer ppdev joydev snd virtio_console virtio_balloon pcspkr serio_raw parport_pc parport pvpanic floppy soundcore i2c_piix4 virtio_blk virtio_net qxl drm_kms_helper ttm drm virtio_pci virtio_ring ata_generic virtio pata_acpi
CPU: 1 PID: 1121 Comm: nfsv4.1-svc Not tainted 3.19.0-rc4+ #25
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140709_153950- 04/01/2014
0000000000000000 000000004e5e3f73 ffff8800b998fb48 ffffffff8186ac78
0000000000000000 ffff8800b998fba0 ffff8800b998fb88 ffffffff810ac9da
ffff8800b998fb68 ffffffff81c923e7 00000000000004d9 0000000000000000
Call Trace:
[] dump_stack+0x4c/0x65
[] warn_slowpath_common+0x8a/0xc0
[] warn_slowpath_fmt+0x55/0x70
[] ? prepare_to_wait+0x2f/0x90
[] ? prepare_to_wait+0x2f/0x90
[] __might_sleep+0xbd/0xd0
[] kmem_cache_alloc_trace+0x243/0x430
[] ? groups_alloc+0x3e/0x130
[] groups_alloc+0x3e/0x130
[] svcauth_unix_accept+0x16e/0x290 [sunrpc]
[] svc_authenticate+0xe1/0xf0 [sunrpc]
[] svc_process_common+0x244/0x6a0 [sunrpc]
[] bc_svc_process+0x1c4/0x260 [sunrpc]
[] nfs41_callback_svc+0x128/0x1f0 [nfsv4]
[] ? wait_woken+0xc0/0xc0
[] ? nfs4_callback_svc+0x60/0x60 [nfsv4]
[] kthread+0x11f/0x140
[] ? local_clock+0x15/0x30
[] ? kthread_create_on_node+0x250/0x250
[] ret_from_fork+0x7c/0xb0
[] ? kthread_create_on_node+0x250/0x250
---[ end trace 675220a11e30f4f2 ]---nfs41_callback_svc does most of its work while in TASK_INTERRUPTIBLE,
which is just wrong. Fix that by finishing the wait immediately if we've
found that the list has something on it.Also, we don't expect this kthread to accept signals, so we should be
using a TASK_UNINTERRUPTIBLE sleep instead. That however, opens us up
hung task warnings from the watchdog, so have the schedule_timeout
wake up every 60s if there's no callback activity.Reported-by: "J. Bruce Fields"
Signed-off-by: Jeff Layton
Signed-off-by: Trond Myklebust
Signed-off-by: Greg Kroah-Hartman -
commit 14460dbaf7a5a0488963fdb8232ad5c8a8cca7b7 upstream.
Current code checks "clk_delay_cycles > 0" to know whether the optional
"mrvl,clk_delay_cycles" is set or not. But of_property_read_u32() doesn't
touch clk_delay_cycles if the property is not set. And type of
clk_delay_cycles is u32, so we may always set pdata->clk_delay_cycles as a
random value.This patch fix this problem by check the return value of of_property_read_u32()
to know whether the optional clk-delay-cycles is set or not.Signed-off-by: Jisheng Zhang
Signed-off-by: Ulf Hansson
Signed-off-by: Greg Kroah-Hartman -
commit 7818b0aab87b680fb10f68eccebeeb6cd8283c73 upstream.
Inspection shows that newlines are missing from several kernel messages
in em28xx-audio. Fix these.Fixes: 1b3fd2d34266 ("[media] em28xx-audio: don't hardcode audio URB calculus")
Signed-off-by: Russell King
Reviewed-by: Frank Schäfer
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 0418ca6073478f54f1da2e4013fa50d36838de75 upstream.
The lockdep splat addressed in a previous commit revealed that at
least one message in em28xx-input.c was missing a new line:em28178 #0: Closing input extensionINFO: trying to register non-static key.
Further inspection shows several other messages also miss a new line.
These will be fixed in a subsequent patch.Fixes: aa929ad783c0 ("[media] em28xx: print a message at disconnect")
Signed-off-by: Russell King
Reviewed-by: Frank Schäfer
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit c2ced1719a1b903350955a511e1666e6d05a7f5b upstream.
Update driver "mask_interrupts" before enable/disable hardware interrupt
in order to avoid missing interrupts because of "mask_interrupts" still
set to 1 and hardware interrupts are enabled.Signed-off-by: Sumit Saxena
Signed-off-by: Chaitra Basappa
Reviewed-by: Martin K. Petersen
Signed-off-by: Christoph Hellwig
Signed-off-by: Greg Kroah-Hartman -
commit faeed51bb65ce0241052d8dc24ac331ade12e976 upstream.
enable_irq_wakeup returns 0 in case it correctly enabled the IRQ to
generate the wakeup event (and thus resume should call disable_irq_wake).
Currently gpio-charger driver has this logic inverted. Correct that thus
correcting enable/disable_irq_wake() calls balance.Signed-off-by: Dmitry Eremin-Solenikov
Signed-off-by: Sebastian Reichel
Signed-off-by: Greg Kroah-Hartman -
commit 478913fdbdfd4a781d91c993eb86838620fe7421 upstream.
The driver mismatched 'num_supplicants' with 'num_supplies' of
power_supply structure.It provided list of supplicants (power_supply.supplied_to) but did
not set the number of supplicants. Instead it set the num_supplies which
is used when iterating over number of supplies (power_supply.supplied_from).As a result the list of supplicants was ignored by core because its size
was 0.Signed-off-by: Krzysztof Kozlowski
Fixes: d7bf353fd0aa ("bq24190_charger: Add support for TI BQ24190 Battery Charger")
Signed-off-by: Sebastian Reichel
Signed-off-by: Greg Kroah-Hartman -
commit 24727b45b484e8937dcde53fa8d1aa70ac30ec0c upstream.
Driver forgot to unregister power supply if request_threaded_irq()
failed in probe(). In such case the memory associated with power supply
leaked.Signed-off-by: Krzysztof Kozlowski
Fixes: a830d28b48bf ("power_supply: Enable battery-charger for 88pm860x")
Signed-off-by: Sebastian Reichel
Signed-off-by: Greg Kroah-Hartman -
commit 7eb71e0351fbb1b242ae70abb7bb17107fe2f792 upstream.
It turns out it's possible to get __remove_osd() called twice on the
same OSD. That doesn't sit well with rb_erase() - depending on the
shape of the tree we can get a NULL dereference, a soft lockup or
a random crash at some point in the future as we end up touching freed
memory. One scenario that I was able to reproduce is as follows:con_fault_finish()
osd_reset()
ceph_osdc_handle_map()
kick_requests()
reset_changed_osds()
__reset_osd()
__remove_osd()
__kick_osd_requests()
__reset_osd()
__remove_osd()
Signed-off-by: Ilya Dryomov
Reviewed-by: Sage Weil
Reviewed-by: Alex Elder
Signed-off-by: Greg Kroah-Hartman -
commit cc9f1f518cec079289d11d732efa490306b1ddad upstream.
No reason to use BUG_ON for osd request list assertions.
Signed-off-by: Ilya Dryomov
Reviewed-by: Alex Elder
Signed-off-by: Greg Kroah-Hartman -
commit 7c6e6fc53e7335570ed82f77656cedce1502744e upstream.
It is important that both regular and lingering requests lists are
empty when the OSD is removed.Signed-off-by: Ilya Dryomov
Reviewed-by: Alex Elder
Signed-off-by: Greg Kroah-Hartman -
commit 3ce465e04bfd8de9956d515d6e9587faac3375dc upstream.
Export the _save_fp asm function used by the lose_fpu(1) macro to GPL
modules so that KVM can make use of it when it is built as a module.This fixes the following build error when CONFIG_KVM=m due to commit
f798217dfd03 ("KVM: MIPS: Don't leak FPU/DSP to guest"):ERROR: "_save_fp" [arch/mips/kvm/kvm.ko] undefined!
Signed-off-by: James Hogan
Fixes: f798217dfd03 (KVM: MIPS: Don't leak FPU/DSP to guest)
Cc: Paolo Bonzini
Cc: Ralf Baechle
Cc: Paul Burton
Cc: Gleb Natapov
Cc: kvm@vger.kernel.org
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/9260/
Signed-off-by: Ralf Baechle
[james.hogan@imgtec.com: Only export when CPU_R4K_FPU=y prior to v3.16,
so as not to break the Octeon build which excludes FPU support. KVM
depends on MIPS32r2 anyway.]
Signed-off-by: James Hogan
Signed-off-by: Greg Kroah-Hartman -
commit f0153c3d948c1764f6c920a0675d86fc1d75813e upstream.
RME RayDAT and AIO use a fixed buffer size of 16384 samples. With period
sizes of 32-4096, this translates to 4-512 periods.The older RME cards have a variable buffer size but require exactly two
periods.This patch enforces nperiods=2 on those cards.
Signed-off-by: Adrian Knoth
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit e4940626defdf6c92da1052ad3f12741c1a28c90 upstream.
The problem here is that we check:
if (dev >= SNDRV_CARDS)
Then we increment "dev".
if (!joystick_port[dev++])
Then we use it as an offset into a array with SNDRV_CARDS elements.
if (!request_region(joystick_port[dev], 8, "Riptide gameport")) {
This has 3 effects:
1) If you use the module option to specify the joystick port then it has
to be shifted one space over.
2) The wrong error message will be printed on failure if you have over
32 cards.
3) Static checkers will correctly complain that are off by one.Fixes: db1005ec6ff8 ('ALSA: riptide - Fix joystick resource handling')
Signed-off-by: Dan Carpenter
Signed-off-by: Takashi Iwai
Signed-off-by: Greg Kroah-Hartman -
commit 15e1ce33182d1d5dbd8efe8d382b9352dc857527 upstream.
A quirk of some older firmwares that report endpoint pipe type as PIPE_BULK
but the endpoint otheriwse functions as interrupt.Check if usb_endpoint_type is USB_ENDPOINT_XFER_BULK and set as usb_rcvbulkpipe.
Signed-off-by: Malcolm Priestley
Signed-off-by: Mauro Carvalho Chehab
Signed-off-by: Greg Kroah-Hartman -
commit 72978b2fe2f2cdf9f319c6c6dcdbe92b38de2be2 upstream.
Commit 61a734d305e1 ("xen/manage: Always freeze/thaw processes when
suspend/resuming") ensured that userspace processes were always frozen
before suspending to reduce interaction issues when resuming devices.
However, freeze_processes() does not freeze kernel threads. Freeze
kernel threads as well to prevent deadlocks with the khubd thread when
resuming devices.This is what native suspend and resume does.
Example deadlock:
[ 7279.648010] [] ? xen_poll_irq_timeout+0x3e/0x50
[ 7279.648010] [] xen_poll_irq+0x10/0x20
[ 7279.648010] [] xen_lock_spinning+0xb3/0x120
[ 7279.648010] [] __raw_callee_save_xen_lock_spinning+0x11/0x20
[ 7279.648010] [] ? usb_control_msg+0xe6/0x120
[ 7279.648010] [] ? _raw_spin_lock_irq+0x50/0x60
[ 7279.648010] [] wait_for_completion+0xac/0x160
[ 7279.648010] [] ? try_to_wake_up+0x2c0/0x2c0
[ 7279.648010] [] dpm_wait+0x32/0x40
[ 7279.648010] [] device_resume+0x90/0x210
[ 7279.648010] [] dpm_resume+0x121/0x250
[ 7279.648010] [] ? xenbus_dev_request_and_reply+0xc0/0xc0
[ 7279.648010] [] dpm_resume_end+0x15/0x30
[ 7279.648010] [] do_suspend+0x10a/0x200
[ 7279.648010] [] ? xen_pre_suspend+0x20/0x20
[ 7279.648010] [] shutdown_handler+0x120/0x150
[ 7279.648010] [] xenwatch_thread+0x9f/0x160
[ 7279.648010] [] ? finish_wait+0x80/0x80
[ 7279.648010] [] kthread+0xc9/0xe0
[ 7279.648010] [] ? flush_kthread_worker+0x80/0x80
[ 7279.648010] [] ret_from_fork+0x7c/0xb0
[ 7279.648010] [] ? flush_kthread_worker+0x80/0x80[ 7441.216287] INFO: task khubd:89 blocked for more than 120 seconds.
[ 7441.219457] Tainted: G X 3.13.11-ckt12.kz #1
[ 7441.222176] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 7441.225827] khubd D ffff88003f433440 0 89 2 0x00000000
[ 7441.229258] ffff88003ceb9b98 0000000000000046 ffff88003ce83000 0000000000013440
[ 7441.232959] ffff88003ceb9fd8 0000000000013440 ffff88003cd13000 ffff88003ce83000
[ 7441.236658] 0000000000000286 ffff88003d3e0000 ffff88003ceb9bd0 00000001001aa01e
[ 7441.240415] Call Trace:
[ 7441.241614] [] schedule+0x29/0x70
[ 7441.243930] [] schedule_timeout+0x166/0x2c0
[ 7441.246681] [] ? call_timer_fn+0x110/0x110
[ 7441.249339] [] schedule_timeout_uninterruptible+0x1e/0x20
[ 7441.252644] [] msleep+0x20/0x30
[ 7441.254812] [] hub_port_reset+0xf0/0x580
[ 7441.257400] [] hub_port_init+0x75/0xb40
[ 7441.259981] [] ? update_autosuspend+0x39/0x60
[ 7441.262817] [] ? pm_runtime_set_autosuspend_delay+0x50/0xa0
[ 7441.266212] [] hub_thread+0x71a/0x1750
[ 7441.268728] [] ? finish_wait+0x80/0x80
[ 7441.271272] [] ? usb_port_resume+0x670/0x670
[ 7441.274067] [] kthread+0xc9/0xe0
[ 7441.276305] [] ? flush_kthread_worker+0x80/0x80
[ 7441.279131] [] ret_from_fork+0x7c/0xb0
[ 7441.281659] [] ? flush_kthread_worker+0x80/0x80Signed-off-by: Ross Lagerwall
Signed-off-by: David Vrabel
Signed-off-by: Greg Kroah-Hartman -
commit 61882b63171736571e1139ab5aa929e3bb336016 upstream.
The two functions s3c2416_cpufreq_driver_init and s3c_cpufreq_register
are marked init but are called from a context that might be run after
the __init sections are discarded, as the compiler points out:WARNING: vmlinux.o(.data+0x1ad9dc): Section mismatch in reference from the variable s3c2416_cpufreq_driver to the function .init.text:s3c2416_cpufreq_driver_init()
WARNING: drivers/built-in.o(.text+0x35b5dc): Section mismatch in reference from the function s3c2410a_cpufreq_add() to the function .init.text:s3c_cpufreq_register()This removes the __init markings.
Signed-off-by: Arnd Bergmann
Acked-by: Viresh Kumar
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman -
commit d4d4eda23794c701442e55129dd4f8f2fefd5e4d upstream.
On Dell Latitude C600 laptop with Pentium 3 850MHz processor, the
speedstep-smi driver sometimes loads and sometimes doesn't load with
"change to state X failed" message.The hardware sometimes refuses to change frequency and in this case, we
need to retry later. I found out that we need to enable interrupts while
waiting. When we enable interrupts, the hardware blockage that prevents
frequency transition resolves and the transition is possible. With
disabled interrupts, the blockage doesn't resolve (no matter how long do
we wait). The exact reasons for this hardware behavior are unknown.This patch enables interrupts in the function speedstep_set_state that can
be called with disabled interrupts. However, this function is called with
disabled interrupts only from speedstep_get_freqs, so it shouldn't cause
any problem.Signed-off-by: Mikulas Patocka
Signed-off-by: Rafael J. Wysocki
Signed-off-by: Greg Kroah-Hartman
