aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-09-29af_unix: return data from multiple SKBs on recv() with MSG_PEEK flagAaron Conole1-1/+14
AF_UNIX sockets now return multiple skbs from recv() when MSG_PEEK flag is set. This is referenced in kernel bugzilla #12323 @ https://bugzilla.kernel.org/show_bug.cgi?id=12323 As described both in the BZ and lkml thread @ http://lkml.org/lkml/2008/1/8/444 calling recv() with MSG_PEEK on an AF_UNIX socket only reads a single skb, where the desired effect is to return as much skb data has been queued, until hitting the recv buffer size (whichever comes first). The modified MSG_PEEK path will now move to the next skb in the tree and jump to the again: label, rather than following the natural loop structure. This requires duplicating some of the loop head actions. This was tested using the python socketpair python code attached to the bugzilla issue. Signed-off-by: Aaron Conole <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-09-29af_unix: Convert the unix_sk macro to an inline function for type safetyAaron Conole1-1/+5
As suggested by Eric Dumazet this change replaces the #define with a static inline function to enjoy complaints by the compiler when misusing the API. Signed-off-by: Aaron Conole <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-09-29drm/amdgpu: Restore LCD backlight level on resumeAlex Deucher1-2/+1
Instead of only enabling the backlight (which seems to set it to max brightness), just re-set the current backlight level, which also takes care of enabling the backlight if necessary. Port of radeon commit: drm/radeon: Restore LCD backlight level on resume (>= R5xx) Signed-off-by: Alex Deucher <[email protected]> Cc: [email protected]
2015-09-29drm/radeon: Restore LCD backlight level on resume (>= R5xx)Michel Dänzer1-4/+4
Instead of only enabling the backlight (which seems to set it to max brightness), just re-set the current backlight level, which also takes care of enabling the backlight if necessary. Only the radeon_atom_encoder_dpms_dig part tested on a Kaveri laptop, the radeon_atom_encoder_dpms_avivo part is only compile tested. Cc: [email protected] Signed-off-by: Michel Dänzer <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2015-09-29drm/amdgpu: signedness bug in amdgpu_cs_parser_init()Dan Carpenter1-1/+2
The "i" variable should be signed or it leads to a crash in the error handling code. Fixes: 1d263474c441 ('drm/amdgpu: unwind properly in amdgpu_cs_parser_init()') Signed-off-by: Dan Carpenter <[email protected]> Signed-off-by: Alex Deucher <[email protected]>
2015-09-29blk-mq: fix deadlock when reading cpu_listAkinobu Mita2-4/+7
CPU hotplug handling for blk-mq (blk_mq_queue_reinit) acquires all_q_mutex in blk_mq_queue_reinit_notify() and then removes sysfs entries by blk_mq_sysfs_unregister(). Removing sysfs entry needs to be blocked until the active reference of the kernfs_node to be zero. On the other hand, reading blk_mq_hw_sysfs_cpu sysfs entry (e.g. /sys/block/nullb0/mq/0/cpu_list) acquires all_q_mutex in blk_mq_hw_sysfs_cpus_show(). If these happen at the same time, a deadlock can happen. Because one can wait for the active reference to be zero with holding all_q_mutex, and the other tries to acquire all_q_mutex with holding the active reference. The reason that all_q_mutex is acquired in blk_mq_hw_sysfs_cpus_show() is to avoid reading an imcomplete hctx->cpumask. Since reading sysfs entry for blk-mq needs to acquire q->sysfs_lock, we can avoid deadlock and reading an imcomplete hctx->cpumask by protecting q->sysfs_lock while hctx->cpumask is being updated. Signed-off-by: Akinobu Mita <[email protected]> Reviewed-by: Ming Lei <[email protected]> Cc: Ming Lei <[email protected]> Cc: Wanpeng Li <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2015-09-29blk-mq: avoid inserting requests before establishing new mappingAkinobu Mita3-19/+52
Notifier callbacks for CPU_ONLINE action can be run on the other CPU than the CPU which was just onlined. So it is possible for the process running on the just onlined CPU to insert request and run hw queue before establishing new mapping which is done by blk_mq_queue_reinit_notify(). This can cause a problem when the CPU has just been onlined first time since the request queue was initialized. At this time ctx->index_hw for the CPU, which is the index in hctx->ctxs[] for this ctx, is still zero before blk_mq_queue_reinit_notify() is called by notifier callbacks for CPU_ONLINE action. For example, there is a single hw queue (hctx) and two CPU queues (ctx0 for CPU0, and ctx1 for CPU1). Now CPU1 is just onlined and a request is inserted into ctx1->rq_list and set bit0 in pending bitmap as ctx1->index_hw is still zero. And then while running hw queue, flush_busy_ctxs() finds bit0 is set in pending bitmap and tries to retrieve requests in hctx->ctxs[0]->rq_list. But htx->ctxs[0] is a pointer to ctx0, so the request in ctx1->rq_list is ignored. Fix it by ensuring that new mapping is established before onlined cpu starts running. Signed-off-by: Akinobu Mita <[email protected]> Reviewed-by: Ming Lei <[email protected]> Cc: Jens Axboe <[email protected]> Cc: Ming Lei <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2015-09-29blk-mq: fix q->mq_usage_counter access raceAkinobu Mita1-3/+4
CPU hotplug handling for blk-mq (blk_mq_queue_reinit) accesses q->mq_usage_counter while freezing all request queues in all_q_list. On the other hand, q->mq_usage_counter is deinitialized in blk_mq_free_queue() before deleting the queue from all_q_list. So if CPU hotplug event occurs in the window, percpu_ref_kill() is called with q->mq_usage_counter which has already been marked dead, and it triggers warning. Fix it by deleting the queue from all_q_list earlier than destroying q->mq_usage_counter. Signed-off-by: Akinobu Mita <[email protected]> Reviewed-by: Ming Lei <[email protected]> Cc: Ming Lei <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2015-09-29blk-mq: Fix use after of free q->mq_mapAkinobu Mita1-5/+3
CPU hotplug handling for blk-mq (blk_mq_queue_reinit) updates q->mq_map by blk_mq_update_queue_map() for all request queues in all_q_list. On the other hand, q->mq_map is released before deleting the queue from all_q_list. So if CPU hotplug event occurs in the window, invalid memory access can happen. Fix it by releasing q->mq_map in blk_mq_release() to make it happen latter than removal from all_q_list. Signed-off-by: Akinobu Mita <[email protected]> Suggested-by: Ming Lei <[email protected]> Reviewed-by: Ming Lei <[email protected]> Cc: Ming Lei <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2015-09-29blk-mq: fix sysfs registration/unregistration raceAkinobu Mita4-12/+27
There is a race between cpu hotplug handling and adding/deleting gendisk for blk-mq, where both are trying to register and unregister the same sysfs entries. null_add_dev --> blk_mq_init_queue --> blk_mq_init_allocated_queue --> add to 'all_q_list' (*) --> add_disk --> blk_register_queue --> blk_mq_register_disk (++) null_del_dev --> del_gendisk --> blk_unregister_queue --> blk_mq_unregister_disk (--) --> blk_cleanup_queue --> blk_mq_free_queue --> del from 'all_q_list' (*) blk_mq_queue_reinit --> blk_mq_sysfs_unregister (-) --> blk_mq_sysfs_register (+) While the request queue is added to 'all_q_list' (*), blk_mq_queue_reinit() can be called for the queue anytime by CPU hotplug callback. But blk_mq_sysfs_unregister (-) and blk_mq_sysfs_register (+) in blk_mq_queue_reinit must not be called before blk_mq_register_disk (++) and after blk_mq_unregister_disk (--) is finished. Because '/sys/block/*/mq/' is not exists. There has already been BLK_MQ_F_SYSFS_UP flag in hctx->flags which can be used to track these sysfs stuff, but it is only fixing this issue partially. In order to fix it completely, we just need per-queue flag instead of per-hctx flag with appropriate locking. So this introduces q->mq_sysfs_init_done which is properly protected with all_q_mutex. Also, we need to ensure that blk_mq_map_swqueue() is called with all_q_mutex is held. Since hctx->nr_ctx is reset temporarily and updated in blk_mq_map_swqueue(), so we should avoid blk_mq_register_hctx() seeing the temporary hctx->nr_ctx value in CPU hotplug handling or adding/deleting gendisk . Signed-off-by: Akinobu Mita <[email protected]> Reviewed-by: Ming Lei <[email protected]> Cc: Ming Lei <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2015-09-29blk-mq: avoid setting hctx->tags->cpumask before allocationAkinobu Mita1-1/+8
When unmapped hw queue is remapped after CPU topology is changed, hctx->tags->cpumask has to be set after hctx->tags is setup in blk_mq_map_swqueue(), otherwise it causes null pointer dereference. Fixes: f26cdc8536 ("blk-mq: Shared tag enhancements") Signed-off-by: Akinobu Mita <[email protected]> Cc: Keith Busch <[email protected]> Cc: Ming Lei <[email protected]> Reviewed-by: Christoph Hellwig <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
2015-09-29svcrdma: handle rdma read with a non-zero initial page offsetSteve Wise1-2/+4
The server rdma_read_chunk_lcl() and rdma_read_chunk_frmr() functions were not taking into account the initial page_offset when determining the rdma read length. This resulted in a read who's starting address and length exceeded the base/bounds of the frmr. The server gets an async error from the rdma device and kills the connection, and the client then reconnects and resends. This repeats indefinitely, and the application hangs. Most work loads don't tickle this bug apparently, but one test hit it every time: building the linux kernel on a 16 core node with 'make -j 16 O=/mnt/0' where /mnt/0 is a ramdisk mounted via NFSRDMA. This bug seems to only be tripped with devices having small fastreg page list depths. I didn't see it with mlx4, for instance. Fixes: 0bf4828983df ('svcrdma: refactor marshalling logic') Signed-off-by: Steve Wise <[email protected]> Tested-by: Chuck Lever <[email protected]> Cc: [email protected] Signed-off-by: J. Bruce Fields <[email protected]>
2015-09-29ASoC: imx-ssi: Fix DAI hardware signal inversionsBenoît Thébaudeau1-10/+9
SND_SOC_DAIFMT_{IB|NB}_{IF|NF} are defined as inverting or not BCLK or FRM relatively to what is standard for the specified DAI hardware audio format. Consequently, the absolute polarities of these signals cannot be derived only from these settings as this driver did. The format has to be taken into account too. This fixes inverted left/right channels in I²S mode. Signed-off-by: Benoît Thébaudeau <[email protected]> Acked-by: Nicolin Chen <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2015-09-29spi: sh-msiof: Match renesas,rx-fifo-size in DT bindings doc with driverGeert Uytterhoeven1-1/+1
Commit fe78d0b7691c0274 ("spi: sh-msiof: Fix FIFO size to 64 word from 256 word") changed the default RX FIFO size on R-Car Gen2 SoCs in the driver code, but forgot to update the DT bindings documentation. Signed-off-by: Geert Uytterhoeven <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2015-09-29regulator: axp20x: Fix enable bit indexes for DCDC4 and DCDC5Chen-Yu Tsai1-2/+2
The enable bit indexes for DCDC4 and DCDC5 regulators are off by 1. We haven't run into any problems with this since either the regulators aren't defined in the DT and aren't used, or all the DCDC regulators have the "always-on" property set, as they are almost always used for system critical loads. Signed-off-by: Chen-Yu Tsai <[email protected]> Signed-off-by: Mark Brown <[email protected]> Cc: [email protected]
2015-09-29ASoC: sgtl5000: fix error message output for MicBias voltageGianluca Renzi1-1/+1
Cc: Liam Girdwood <[email protected]> Cc: Takashi Iwai <[email protected]> Cc: Fabio Estevam <[email protected]> Cc: [email protected] Cc: [email protected] Signed-off-by: Gianluca Renzi <[email protected]> Signed-off-by: Mark Brown <[email protected]>
2015-09-29s390/boot/decompression: disable floating point in decompressorChristian Borntraeger1-1/+1
my gcc 5.1 used an ldgr instruction with a register != 0,2,4,6 for spilling/filling into a floating point register in our decompressor. This will cause an AFP-register data exception as the decompressor did not setup the additional floating point registers via cr0. That causes a program check loop that looked like a hang with one "Uncompressing Linux... " message (directly booted via kvm) or a loop of "Uncompressing Linux... " messages (when booted via zipl boot loader). The offending code in my build was 48e400: e3 c0 af ff ff 71 lay %r12,-1(%r10) -->48e406: b3 c1 00 1c ldgr %f1,%r12 48e40a: ec 6c 01 22 02 7f clij %r6,2,12,0x48e64e but gcc could do spilling into an fpr at any function. We can simply disable floating point support at that early stage. Signed-off-by: Christian Borntraeger <[email protected]> Acked-by: Heiko Carstens <[email protected]> Cc: [email protected]
2015-09-29clocksource/drivers/keystone: Fix bad NO_IRQ usageDaniel Lezcano1-1/+1
The current code assumes the 'irq_of_parse_and_map' will return NO_IRQ in case of failure. Unfortunately, the NO_IRQ is not consistent across the different architectures and we must not rely on it. NO_IRQ is equal to '-1' on ARM and 'irq_of_parse_and_map' returns '0' in case of an error. Hence, the latter won't be detected and will lead to a crash. Fix this by just checking 'irq' is different from zero. Signed-off-by: Daniel Lezcano <[email protected]>
2015-09-29clocksource/drivers/rockchip: Fix bad NO_IRQ usageDaniel Lezcano1-1/+1
The current code assumes the 'irq_of_parse_and_map' will return NO_IRQ in case of failure. Unfortunately, the NO_IRQ is not consistent across the different architectures and we must not rely on it. NO_IRQ is equal to '-1' on ARM and 'irq_of_parse_and_map' returns '0' in case of an error. Hence, the latter won't be detected and will lead to a crash. Fix this by just checking 'irq' is different from zero. Signed-off-by: Daniel Lezcano <[email protected]>
2015-09-29UBI: return ENOSPC if no enough space availableshengyong2-0/+2
UBI: attaching mtd1 to ubi0 UBI: scanning is finished UBI error: init_volumes: not enough PEBs, required 706, available 686 UBI error: ubi_wl_init: no enough physical eraseblocks (-20, need 1) UBI error: ubi_attach_mtd_dev: failed to attach mtd1, error -12 <= NOT ENOMEM UBI error: ubi_init: cannot attach mtd1 If available PEBs are not enough when initializing volumes, return -ENOSPC directly. If available PEBs are not enough when initializing WL, return -ENOSPC instead of -ENOMEM. Cc: [email protected] Signed-off-by: Sheng Yong <[email protected]> Signed-off-by: Richard Weinberger <[email protected]> Reviewed-by: David Gstir <[email protected]>
2015-09-29UBI: Validate data_sizeRichard Weinberger1-0/+5
Make sure that data_size is less than LEB size. Otherwise a handcrafted UBI image is able to trigger an out of bounds memory access in ubi_compare_lebs(). Cc: [email protected] Signed-off-by: Richard Weinberger <[email protected]> Reviewed-by: David Gstir <[email protected]>
2015-09-29UBIFS: Kill unneeded locking in ubifs_init_securityRichard Weinberger1-3/+0
Fixes the following lockdep splat: [ 1.244527] ============================================= [ 1.245193] [ INFO: possible recursive locking detected ] [ 1.245193] 4.2.0-rc1+ #37 Not tainted [ 1.245193] --------------------------------------------- [ 1.245193] cp/742 is trying to acquire lock: [ 1.245193] (&sb->s_type->i_mutex_key#9){+.+.+.}, at: [<ffffffff812b3f69>] ubifs_init_security+0x29/0xb0 [ 1.245193] [ 1.245193] but task is already holding lock: [ 1.245193] (&sb->s_type->i_mutex_key#9){+.+.+.}, at: [<ffffffff81198e7f>] path_openat+0x3af/0x1280 [ 1.245193] [ 1.245193] other info that might help us debug this: [ 1.245193] Possible unsafe locking scenario: [ 1.245193] [ 1.245193] CPU0 [ 1.245193] ---- [ 1.245193] lock(&sb->s_type->i_mutex_key#9); [ 1.245193] lock(&sb->s_type->i_mutex_key#9); [ 1.245193] [ 1.245193] *** DEADLOCK *** [ 1.245193] [ 1.245193] May be due to missing lock nesting notation [ 1.245193] [ 1.245193] 2 locks held by cp/742: [ 1.245193] #0: (sb_writers#5){.+.+.+}, at: [<ffffffff811ad37f>] mnt_want_write+0x1f/0x50 [ 1.245193] #1: (&sb->s_type->i_mutex_key#9){+.+.+.}, at: [<ffffffff81198e7f>] path_openat+0x3af/0x1280 [ 1.245193] [ 1.245193] stack backtrace: [ 1.245193] CPU: 2 PID: 742 Comm: cp Not tainted 4.2.0-rc1+ #37 [ 1.245193] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140816_022509-build35 04/01/2014 [ 1.245193] ffffffff8252d530 ffff88007b023a38 ffffffff814f6f49 ffffffff810b56c5 [ 1.245193] ffff88007c30cc80 ffff88007b023af8 ffffffff810a150d ffff88007b023a68 [ 1.245193] 000000008101302a ffff880000000000 00000008f447e23f ffffffff8252d500 [ 1.245193] Call Trace: [ 1.245193] [<ffffffff814f6f49>] dump_stack+0x4c/0x65 [ 1.245193] [<ffffffff810b56c5>] ? console_unlock+0x1c5/0x510 [ 1.245193] [<ffffffff810a150d>] __lock_acquire+0x1a6d/0x1ea0 [ 1.245193] [<ffffffff8109fa78>] ? __lock_is_held+0x58/0x80 [ 1.245193] [<ffffffff810a1a93>] lock_acquire+0xd3/0x270 [ 1.245193] [<ffffffff812b3f69>] ? ubifs_init_security+0x29/0xb0 [ 1.245193] [<ffffffff814fc83b>] mutex_lock_nested+0x6b/0x3a0 [ 1.245193] [<ffffffff812b3f69>] ? ubifs_init_security+0x29/0xb0 [ 1.245193] [<ffffffff812b3f69>] ? ubifs_init_security+0x29/0xb0 [ 1.245193] [<ffffffff812b3f69>] ubifs_init_security+0x29/0xb0 [ 1.245193] [<ffffffff8128e286>] ubifs_create+0xa6/0x1f0 [ 1.245193] [<ffffffff81198e7f>] ? path_openat+0x3af/0x1280 [ 1.245193] [<ffffffff81195d15>] vfs_create+0x95/0xc0 [ 1.245193] [<ffffffff8119929c>] path_openat+0x7cc/0x1280 [ 1.245193] [<ffffffff8109ffe3>] ? __lock_acquire+0x543/0x1ea0 [ 1.245193] [<ffffffff81088f20>] ? sched_clock_cpu+0x90/0xc0 [ 1.245193] [<ffffffff81088c00>] ? calc_global_load_tick+0x60/0x90 [ 1.245193] [<ffffffff81088f20>] ? sched_clock_cpu+0x90/0xc0 [ 1.245193] [<ffffffff811a9cef>] ? __alloc_fd+0xaf/0x180 [ 1.245193] [<ffffffff8119ac55>] do_filp_open+0x75/0xd0 [ 1.245193] [<ffffffff814ffd86>] ? _raw_spin_unlock+0x26/0x40 [ 1.245193] [<ffffffff811a9cef>] ? __alloc_fd+0xaf/0x180 [ 1.245193] [<ffffffff81189bd9>] do_sys_open+0x129/0x200 [ 1.245193] [<ffffffff81189cc9>] SyS_open+0x19/0x20 [ 1.245193] [<ffffffff81500717>] entry_SYSCALL_64_fastpath+0x12/0x6f While the lockdep splat is a false positive, becuase path_openat holds i_mutex of the parent directory and ubifs_init_security() tries to acquire i_mutex of a new inode, it reveals that taking i_mutex in ubifs_init_security() is in vain because it is only being called in the inode allocation path and therefore nobody else can see the inode yet. Cc: [email protected] # 3.20- Reported-and-tested-by: Boris Brezillon <[email protected]> Reviewed-and-tested-by: Dongsheng Yang <[email protected]> Signed-off-by: Richard Weinberger <[email protected]> Signed-off-by: [email protected]
2015-09-29mmc: pxamci: fix card detect with slot-gpio APIRobert Jarzmik1-44/+22
Move pxamci to mmc slot-gpio API to fix interrupt request. It fixes the case where the card detection is on a gpio expander, on I2C for example on zylonite board. In this case, the card detect netsted interrupt is called from a threaded interrupt. The request_irq() fails, because a hard irq cannot be a nested interrupt from a threaded interrupt (set __setup_irq()). This was tested on zylonite and mioa701 boards. Signed-off-by: Robert Jarzmik <[email protected]> Cc: Petr Cvek <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
2015-09-29mmc: sunxi: Fix clk-delay settingsHans de Goede1-14/+39
In recent allwinner kernel sources the mmc clk-delay settings have been slightly tweaked, and for sun9i they are completely different then what we are using. This commit brings us in sync with what allwinner does, fixing problems accessing sdcards on some A33 devices (and likely others). For pre sun9i hardware this makes the following changes: -At 400Khz change the sample delay from 7 to 0 (introduced in A31 sdk) -At 50 Mhz change the sample delay from 5 to 4 (introduced in A23 sdk) This also drops the clk-delay calculation for clocks > 50 MHz, we do not need this as we've: mmc->f_max = 50000000, and the delays in the old code were not correct (at 100 MHz the delay must be a multiple of 60, at 200 MHz a multiple of 120). Signed-off-by: Hans de Goede <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
2015-09-29mmc: core: Don't return an error for CD/WP GPIOs when GPIOLIB is unsetUlf Hansson1-2/+2
When CONFIG_GPIOLIB is unset, its stubs will return -ENOSYS. That means when the mmc core parses DT for CD/WP GPIOs via mmc_of_parse(), -ENOSYS becomes propagated to the caller. Typically this means that the mmc host driver fails to probe. As the CD/WP GPIOs are already treated as optional, let's extend that to cover the case when CONFIG_GPIOLIB is unset. Reported-by: Michal Simek <[email protected]> Fixes: 16b23787fc70 ("mmc: sdhci-of-arasan: Call OF parsing for MMC") Signed-off-by: Ulf Hansson <[email protected]> Tested-by: Michal Simek <[email protected]> Acked-by: Venu Byravarasu <[email protected]>
2015-09-29Merge tag 'keys-fixes-20150925' of ↵James Morris5-30/+82
git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs into for-linus Keyrings fixes from David Howells, for current Linus.
2015-09-29ARM: dts: Fix wrong clock binding for sysmmu_fimd1_1 on exynos5420Joonyoung Shim1-1/+1
The sysmmu_fimd1_1 should bind the clock CLK_SMMU_FIMD1M1, not the clock CLK_SMMU_FIMD1M0. CLK_SMMU_FIMD1M0 is a clock for the sysmmu_fimd1_0. This wrong clock binding causes the problem that is blocked in iommu_map function when IOMMU is enabled and exynos-drm driver tries to allocate buffer via DMA mapping API on Odroid-XU3 board. Fixes: b70045167815 ("ARM: dts: add sysmmu nodes for exynos5420") Signed-off-by: Joonyoung Shim <[email protected]> Cc: <[email protected]> # v4.2 Reviewed-by: Javier Martinez Canillas <[email protected]> Acked-by: Marek Szyprowski <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]>
2015-09-29ARM: dts: Fix bootup thermal issue on smdk5250Yadwinder Singh Brar1-0/+1
With default config on smdk5250 latest tree throws below message: [ 2.226049] thermal thermal_zone0: critical temperature reached(224 C),shutting down [ 2.227840] reboot: Failed to start orderly shutdown: forcing the issue and hangs randomly because it reads wrong temperature value. I can't figure out any direct relation between LDO10 and TMU from board schematics which I have. So making LDO10 always-on to fix issue for now. Signed-off-by: Yadwinder Singh Brar <[email protected]> [pankaj.dubey: resubmitted after rebasing to latest kgene tree] Signed-off-by: Pankaj Dubey <[email protected]> Tested-by: Pankaj Dubey <[email protected]> Signed-off-by: Krzysztof Kozlowski <[email protected]>
2015-09-28net: sctp: Don't use 64 kilobyte lookup table for four elementsDenys Vlasenko1-9/+11
Seemingly innocuous sctp_trans_state_to_prio_map[] array is way bigger than it looks, since "[SCTP_UNKNOWN] = 2" expands into "[0xffff] = 2" ! This patch replaces it with switch() statement. Signed-off-by: Denys Vlasenko <[email protected]> CC: Vlad Yasevich <[email protected]> CC: Neil Horman <[email protected]> CC: Marcelo Ricardo Leitner <[email protected]> CC: [email protected] CC: [email protected] CC: [email protected] Acked-by: Marcelo Ricardo Leitner <[email protected]> Acked-by: Neil Horman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-09-28l2tp: protect tunnel->del_work by ref_countAlexander Couzens1-2/+9
There is a small chance that tunnel_free() is called before tunnel->del_work scheduled resulting in a zero pointer dereference. Signed-off-by: Alexander Couzens <[email protected]> Acked-by: James Chapman <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-09-28net/ibm/emac: bump version numbers for correct work with ethtoolIvan Mikhaylov1-3/+3
The size of the MAC register dump used to be the size specified by the reg property in the device tree. Userland has no good way of finding out that size, and it was not specified consistently for each MAC type, so ethtool would end up printing junk at the end of the register dump if the device tree didn't match the size it assumed. Using the new version numbers indicates unambiguously that the size of the MAC register dump is dependent only on the MAC type. Fixes: 5369c71f7ca2 ("net/ibm/emac: fix size of emac dump memory areas") Signed-off-by: Ivan Mikhaylov <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-09-28Merge branch 'sctp-accept-deadlock'David S. Miller1-20/+24
Karl Heiss says: ==================== sctp: Fix SCTP deadlock These patches fix a deadlock during accept() of an SCTP connection. The first patch fixes whitespace issues. The second patch actually fixes the deadlock race. ==================== Signed-off-by: David S. Miller <[email protected]>
2015-09-28sctp: Prevent soft lockup when sctp_accept() is called during a timeout eventKarl Heiss1-19/+23
A case can occur when sctp_accept() is called by the user during a heartbeat timeout event after the 4-way handshake. Since sctp_assoc_migrate() changes both assoc->base.sk and assoc->ep, the bh_sock_lock in sctp_generate_heartbeat_event() will be taken with the listening socket but released with the new association socket. The result is a deadlock on any future attempts to take the listening socket lock. Note that this race can occur with other SCTP timeouts that take the bh_lock_sock() in the event sctp_accept() is called. BUG: soft lockup - CPU#9 stuck for 67s! [swapper:0] ... RIP: 0010:[<ffffffff8152d48e>] [<ffffffff8152d48e>] _spin_lock+0x1e/0x30 RSP: 0018:ffff880028323b20 EFLAGS: 00000206 RAX: 0000000000000002 RBX: ffff880028323b20 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff880028323be0 RDI: ffff8804632c4b48 RBP: ffffffff8100bb93 R08: 0000000000000000 R09: 0000000000000000 R10: ffff880610662280 R11: 0000000000000100 R12: ffff880028323aa0 R13: ffff8804383c3880 R14: ffff880028323a90 R15: ffffffff81534225 FS: 0000000000000000(0000) GS:ffff880028320000(0000) knlGS:0000000000000000 CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b CR2: 00000000006df528 CR3: 0000000001a85000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process swapper (pid: 0, threadinfo ffff880616b70000, task ffff880616b6cab0) Stack: ffff880028323c40 ffffffffa01c2582 ffff880614cfb020 0000000000000000 <d> 0100000000000000 00000014383a6c44 ffff8804383c3880 ffff880614e93c00 <d> ffff880614e93c00 0000000000000000 ffff8804632c4b00 ffff8804383c38b8 Call Trace: <IRQ> [<ffffffffa01c2582>] ? sctp_rcv+0x492/0xa10 [sctp] [<ffffffff8148c559>] ? nf_iterate+0x69/0xb0 [<ffffffff814974a0>] ? ip_local_deliver_finish+0x0/0x2d0 [<ffffffff8148c716>] ? nf_hook_slow+0x76/0x120 [<ffffffff814974a0>] ? ip_local_deliver_finish+0x0/0x2d0 [<ffffffff8149757d>] ? ip_local_deliver_finish+0xdd/0x2d0 [<ffffffff81497808>] ? ip_local_deliver+0x98/0xa0 [<ffffffff81496ccd>] ? ip_rcv_finish+0x12d/0x440 [<ffffffff81497255>] ? ip_rcv+0x275/0x350 [<ffffffff8145cfeb>] ? __netif_receive_skb+0x4ab/0x750 ... With lockdep debugging: ===================================== [ BUG: bad unlock balance detected! ] ------------------------------------- CslRx/12087 is trying to release lock (slock-AF_INET) at: [<ffffffffa01bcae0>] sctp_generate_timeout_event+0x40/0xe0 [sctp] but there are no more locks to release! other info that might help us debug this: 2 locks held by CslRx/12087: #0: (&asoc->timers[i]){+.-...}, at: [<ffffffff8108ce1f>] run_timer_softirq+0x16f/0x3e0 #1: (slock-AF_INET){+.-...}, at: [<ffffffffa01bcac3>] sctp_generate_timeout_event+0x23/0xe0 [sctp] Ensure the socket taken is also the same one that is released by saving a copy of the socket before entering the timeout event critical section. Signed-off-by: Karl Heiss <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-09-28sctp: Whitespace fixKarl Heiss1-2/+2
Fix indentation in sctp_generate_heartbeat_event. Signed-off-by: Karl Heiss <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-09-28i40e/i40evf: check for stopped admin queueMitch Williams2-0/+18
It's possible that while we are waiting for the spinlock, another entity (that owns the spinlock) has shut down the admin queue. If we then attempt to use the queue, we will panic. Add a check for this condition on the receive side. This matches an existing check on the send queue side. Signed-off-by: Mitch Williams <[email protected]> Acked-by: Jesse Brandeburg <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-09-28i40e: fix VLAN inside VXLANJesse Brandeburg1-1/+2
Previously to this patch, the hardware was removing VLAN tags from the inner header of VXLAN packets. The hardware configuration can be changed to leave the packet alone since that is what the linux stack expects for this type of VLAN in VXLAN packet. Signed-off-by: Jesse Brandeburg <[email protected]> Tested-by: Andrew Bowers <[email protected]> Signed-off-by: Jeff Kirsher <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-09-29ARM: shmobile: r8a7791 dtsi: Add CPG/MSTP Clock Domain for soundGeert Uytterhoeven1-0/+1
797a0626e08c ("ARM: shmobile: r8a7791 dtsi: Add CPG/MSTP Clock Domain") added CPG/MSTP clock-cells domain support, but it was missing sound support. This patch adds it. Signed-off-by: Geert Uytterhoeven <[email protected]> Tested-by: Kuninori Morimoto <[email protected]> [horms: updated commit id referred to in changelog] Signed-off-by: Simon Horman <[email protected]>
2015-09-29ARM: shmobile: r8a7790 dtsi: Add CPG/MSTP Clock Domain for soundGeert Uytterhoeven1-0/+1
484adb005886 ("ARM: shmobile: r8a7790 dtsi: Add CPG/MSTP Clock Domain") added CPG/MSTP clock-cells domain support, but it was missing sound support. This patch adds it. Signed-off-by: Geert Uytterhoeven <[email protected]> Tested-by: Kuninori Morimoto <[email protected]> [horms: Updated commit id referred to in changelog] Signed-off-by: Simon Horman <[email protected]>
2015-09-28Input: elan_i2c - add all valid ic type for i2c/smbusduson1-1/+10
Signed-off-by: Duson Lin <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>
2015-09-28Input: zhenhua - ensure we have BITREVERSEAndrew Morton1-0/+1
It uses bitrev8(), so it must ensure that lib/bitrev.o gets included in vmlinux. Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>
2015-09-28arm-cci500: Don't enable PMU driver by defaultSuzuki K. Poulose1-1/+0
Disable building CCI-500 PMU driver by default. Reported-by: Russell King <[email protected]> Cc: Punit Agrawal <[email protected]> Cc: Mark Rutland <[email protected]> Cc: [email protected] Signed-off-by: Suzuki K. Poulose <[email protected]> Signed-off-by: Olof Johansson <[email protected]>
2015-09-28Merge tag 'imx-fixes-4.3' of ↵Olof Johansson3-3/+2
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into fixes The i.MX fixes for 4.3: - One fix for i.MX6 Rex Pro board to remove a duplicated pinctrl entry which causes error for USB pinctrl setup. - Fix MC34708 PMIC interrupt level for imx53-qsrb board. * tag 'imx-fixes-4.3' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: ARM: dts: fix usb pin control for imx-rex dts ARM: imx53: qsrb: fix PMIC interrupt level ARM: imx53: include IRQ dt-bindings header Signed-off-by: Olof Johansson <[email protected]>
2015-09-28Input: omap4-keypad - fix memory leakSudip Mukherjee1-1/+1
If omap4_keypad_parse_dt() fails we returned the error code but we missed releasing keypad_data. Signed-off-by: Sudip Mukherjee <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>
2015-09-28x86/xen: Do not clip xen_e820_map to xen_e820_map_entries when sanitizing mapMalcolm Crossley1-1/+1
Sanitizing the e820 map may produce extra E820 entries which would result in the topmost E820 entries being removed. The removed entries would typically include the top E820 usable RAM region and thus result in the domain having signicantly less RAM available to it. Fix by allowing sanitize_e820_map to use the full size of the allocated E820 array. Signed-off-by: Malcolm Crossley <[email protected]> Reviewed-by: Boris Ostrovsky <[email protected]> Cc: <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-09-28Merge branch 'stable' of ↵Linus Torvalds1-0/+1
git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile Pull arch/tile bugfix from Chris Metcalf: "This fixes a bug in 'make allmodconfig'" * 'stable' of git://git.kernel.org/pub/scm/linux/kernel/git/cmetcalf/linux-tile: tile: fix build failure
2015-09-28tile: fix build failureSudip Mukherjee1-0/+1
When building with allmodconfig the build was failing with the error: arch/tile/kernel/usb.c:70:1: warning: data definition has no type or storage class [enabled by default] arch/tile/kernel/usb.c:70:1: error: type defaults to 'int' in declaration of 'arch_initcall' [-Werror=implicit-int] arch/tile/kernel/usb.c:70:1: warning: parameter names (without types) in function declaration [enabled by default] arch/tile/kernel/usb.c:63:19: warning: 'tilegx_usb_init' defined but not used [-Wunused-function] Include linux/module.h to resolve the build failure. Signed-off-by: Sudip Mukherjee <[email protected]> Signed-off-by: Chris Metcalf <[email protected]>
2015-09-28xprtrdma: disconnect and flush cqs before freeing buffersSteve Wise2-4/+7
Otherwise a FRMR completion can cause a touch-after-free crash. In xprt_rdma_destroy(), call rpcrdma_buffer_destroy() only after calling rpcrdma_ep_destroy(). In rpcrdma_ep_destroy(), disconnect the cm_id first which should flush the qp, then drain the cqs, then destroy the qp, and finally destroy the cqs. Signed-off-by: Steve Wise <[email protected]> Tested-by: Chuck Lever <[email protected]> Signed-off-by: Anna Schumaker <[email protected]>
2015-09-28drm/i915: Consider HW CSB write pointer before resetting the sw read pointerMichel Thierry2-7/+34
A previous commit resets the Context Status Buffer (CSB) read pointer in ring init commit c0a03a2e4c4e ("drm/i915: Reset CSB read pointer in ring init") This is generally correct, but this pointer is not reset after suspend/resume in some platforms (cht). In this case, the driver should read the register value instead of resetting the sw read counter to 0. Otherwise we process old events, leading to unwanted pre-emptions or something worse. But in other platforms (bdw) and also during GPU reset or power up, the CSBWP is reset to 0x7 (an invalid number), and in this case the read pointer should be set to 5 (the interrupt code will increment this counter one more time, and will start reading from CSB[0]). v2: When the CSB registers are reset, the read pointer needs to be set to 5, otherwise the first write (CSB[0]) won't be read (Mika). Replace magic numbers with GEN8_CSB_ENTRIES (6) and GEN8_CSB_PTR_MASK (0x07). Cc: Mika Kuoppala <[email protected]> Cc: [email protected] # v4.0+ Signed-off-by: Lei Shen <[email protected]> Signed-off-by: Deepak S <[email protected]> Signed-off-by: Michel Thierry <[email protected]> Reviewed-by: Mika Kuoppala <[email protected]> Signed-off-by: Jani Nikula <[email protected]>
2015-09-28x86/xen: Support kexec/kdump in HVM guests by doing a soft resetVitaly Kuznetsov2-0/+31
Currently there is a number of issues preventing PVHVM Xen guests from doing successful kexec/kdump: - Bound event channels. - Registered vcpu_info. - PIRQ/emuirq mappings. - shared_info frame after XENMAPSPACE_shared_info operation. - Active grant mappings. Basically, newly booted kernel stumbles upon already set up Xen interfaces and there is no way to reestablish them. In Xen-4.7 a new feature called 'soft reset' is coming. A guest performing kexec/kdump operation is supposed to call SCHEDOP_shutdown hypercall with SHUTDOWN_soft_reset reason before jumping to new kernel. Hypervisor (with some help from toolstack) will do full domain cleanup (but keeping its memory and vCPU contexts intact) returning the guest to the state it had when it was first booted and thus allowing it to start over. Doing SHUTDOWN_soft_reset on Xen hypervisors which don't support it is probably OK as by default all unknown shutdown reasons cause domain destroy with a message in toolstack log: 'Unknown shutdown reason code 5. Destroying domain.' which gives a clue to what the problem is and eliminates false expectations. Signed-off-by: Vitaly Kuznetsov <[email protected]> Cc: <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2015-09-28xen/x86: Don't try to write syscall-related MSRs for PV guestsBoris Ostrovsky1-0/+1
For PV guests these registers are set up by hypervisor and thus should not be written by the guest. The comment in xen_write_msr_safe() says so but we still write the MSRs, causing the hypervisor to print a warning. Signed-off-by: Boris Ostrovsky <[email protected]> Reviewed-by: Konrad Rzeszutek Wilk <[email protected]> Signed-off-by: David Vrabel <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.