aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2015-09-30x86/hyperv: Fix the build in the !CONFIG_KEXEC_CORE caseVitaly Kuznetsov1-5/+7
Recent changes in the Hyper-V driver: b4370df2b1f5 ("Drivers: hv: vmbus: add special crash handler") broke the build when CONFIG_KEXEC_CORE is not set: arch/x86/built-in.o: In function `hv_machine_crash_shutdown': arch/x86/kernel/cpu/mshyperv.c:112: undefined reference to `native_machine_crash_shutdown' Decorate all kexec related code with #ifdef CONFIG_KEXEC_CORE. Reported-by: Jim Davis <[email protected]> Reported-by: Stephen Hemminger <[email protected]> Signed-off-by: Vitaly Kuznetsov <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: [email protected] Cc: K. Y. Srinivasan <[email protected]> Cc: Haiyang Zhang <[email protected]> Cc: Greg Kroah-Hartman <[email protected]> Cc: Peter Zijlstra <[email protected]> Cc: Linus Torvalds <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Ingo Molnar <[email protected]>
2015-09-29net: Initialize flow flags in input pathDavid Ahern2-0/+2
The fib_table_lookup tracepoint found 2 places where the flowi4_flags is not initialized. Signed-off-by: David Ahern <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-09-29net: dsa: fix preparation of a port STP updateVivien Didelot1-3/+8
Because of the default 0 value of ret in dsa_slave_port_attr_set, a driver may return -EOPNOTSUPP from the commit phase of a STP state, which triggers a WARN() from switchdev. This happened on a 6185 switch which does not support hardware bridging. Fixes: 3563606258cf ("switchdev: convert STP update to switchdev attr set") Reported-by: Andrew Lunn <[email protected]> Signed-off-by: Vivien Didelot <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-09-29testptp: Silence compiler warnings on ppc64Thomas Huth1-0/+1
When compiling Documentation/ptp/testptp.c the following compiler warnings are printed out: Documentation/ptp/testptp.c: In function ‘main’: Documentation/ptp/testptp.c:367:11: warning: format ‘%lld’ expects argument of type ‘long long int’, but argument 3 has type ‘__s64’ [-Wformat=] event.t.sec, event.t.nsec); ^ Documentation/ptp/testptp.c:505:5: warning: format ‘%lld’ expects argument of type ‘long long int’, but argument 2 has type ‘__s64’ [-Wformat=] (pct+2*i)->sec, (pct+2*i)->nsec); ^ Documentation/ptp/testptp.c:507:5: warning: format ‘%lld’ expects argument of type ‘long long int’, but argument 2 has type ‘__s64’ [-Wformat=] (pct+2*i+1)->sec, (pct+2*i+1)->nsec); ^ Documentation/ptp/testptp.c:509:5: warning: format ‘%lld’ expects argument of type ‘long long int’, but argument 2 has type ‘__s64’ [-Wformat=] (pct+2*i+2)->sec, (pct+2*i+2)->nsec); This happens because __s64 is by default defined as "long" on ppc64, not as "long long". However, to fix these warnings, it's possible to define the __SANE_USERSPACE_TYPES__ so that __s64 gets defined to "long long" on ppc64, too. Signed-off-by: Thomas Huth <[email protected]> Acked-by: Richard Cochran <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-09-29net/mlx4: Handle return codes in mlx4_qp_attach_commonRobb Manes1-3/+4
Both new_steering_entry() and existing_steering_entry() return values based on their success or failure, but currently they fall through silently. This can make troubleshooting difficult, as we were unable to tell which one of these two functions returned errors or specifically what code was returned. This patch remedies that situation by passing the return codes to err, which is returned by mlx4_qp_attach_common() itself. This also addresses a leak in the call to mlx4_bitmap_free() as well. Signed-off-by: Robb Manes <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-09-29dsa: mv88e6xxx: Enable forwarding for unknown to the CPU portAndrew Lunn1-0/+2
Frames destined to an unknown address must be forwarded to the CPU port. Otherwise incoming ARP, dhcp leases, etc, do not work. Signed-off-by: Andrew Lunn <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-09-29skbuff: Fix skb checksum partial check.Pravin B Shelar2-5/+6
Earlier patch 6ae459bda tried to detect void ckecksum partial skb by comparing pull length to checksum offset. But it does not work for all cases since checksum-offset depends on updates to skb->data. Following patch fixes it by validating checksum start offset after skb-data pointer is updated. Negative value of checksum offset start means there is no need to checksum. Fixes: 6ae459bda ("skbuff: Fix skb checksum flag on skb pull") Reported-by: Andrew Vagin <[email protected]> Signed-off-by: Pravin B Shelar <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-09-29Input: psmouse - fix data race in __ps2_commandDmitry Vyukov1-8/+14
The data race happens on ps2dev->cmdcnt and ps2dev->cmdbuf contents. __ps2_command reads that data concurrently with the interrupt handler. As the result, for example, if a response arrives just after the timeout, __ps2_command can copy out garbage from ps2dev->cmdbuf but then see that ps2dev->cmdcnt is 0 and return success. Stop the interrupt handler with serio_pause_rx() before reading the results. The data race was found with KernelThreadSanitizer (KTSAN). Signed-off-by: Dmitry Vyukov <[email protected]> Signed-off-by: Dmitry Torokhov <[email protected]>
2015-09-29net: ipv6: Add RT6_LOOKUP_F_IFACE flag if oif is setDavid Ahern1-1/+2
Wolfgang reported that IPv6 stack is ignoring oif in output route lookups: With ipv6, ip -6 route get always returns the specific route. $ ip -6 r 2001:db8:e2::1 dev enp2s0 proto kernel metric 256 2001:db8:e2::/64 dev enp2s0 metric 1024 2001:db8:e3::1 dev enp3s0 proto kernel metric 256 2001:db8:e3::/64 dev enp3s0 metric 1024 fe80::/64 dev enp3s0 proto kernel metric 256 default via 2001:db8:e3::255 dev enp3s0 metric 1024 $ ip -6 r get 2001:db8:e2::100 2001:db8:e2::100 from :: dev enp2s0 src 2001:db8:e3::1 metric 0 cache $ ip -6 r get 2001:db8:e2::100 oif enp3s0 2001:db8:e2::100 from :: dev enp2s0 src 2001:db8:e3::1 metric 0 cache The stack does consider the oif but a mismatch in rt6_device_match is not considered fatal because RT6_LOOKUP_F_IFACE is not set in the flags. Cc: Wolfgang Nothdurft <[email protected]> Signed-off-by: David Ahern <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-09-29net sysfs: Print link speed as signed integerAlexander Stein1-2/+1
Otherwise 4294967295 (MBit/s) (-1) will be printed when there is no link. Documentation/ABI/testing/sysfs-class-net does not state if this shall be signed or unsigned. Also remove the now unused variable fmt_udec. Signed-off-by: Alexander Stein <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-09-29bna: fix error handlingAndrzej Hajda1-6/+7
Several functions can return negative value in case of error, so their return type should be fixed as well as type of variables to which this value is assigned. The problem has been detected using proposed semantic patch scripts/coccinelle/tests/assign_signed_to_unsigned.cocci [1]. [1]: http://permalink.gmane.org/gmane.linux.kernel/2046107 Signed-off-by: Andrzej Hajda <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2015-09-29Merge branch 'af_unix_MSG_PEEK'David S. Miller2-2/+19
Aaron Conole says: ==================== af_unix: return data from multiple SKBs on recv() with MSG_PEEK flag This patch set implements a bugfix for kernel.org bugzilla #12323, allowing MSG_PEEK to return all queued data on the unix domain socket, not just the data contained in a single SKB. This is the v3 version of this patch, which includes a suggested modification by Eric Dumazet to convert the unix_sk() conversion macro to a static inline function. These patches are independent and can be applied separately. This set was tested over a 24-hour period, utilizing a loop continually executing the bugzilla issue attached python code. It was instrumented with a pr_err_once() ([ 13.798683] unix: went there at least one time). v2->v3: - Added Eric Dumazet's suggestion for #define to static inline - Fixed an issue calling unix_state_lock() with an invalid argument v3->v4: - Eliminated an XXX comment - Changed from goto unlock to explicit unix_state_unlock() and break ==================== Signed-off-by: David S. Miller <[email protected]>
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-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-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-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-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-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-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-28Revert "KVM: x86: zero kvmclock_offset when vcpu0 initializes kvmclock ↵Radim Krčmář2-4/+1
system MSR" Shifting pvclock_vcpu_time_info.system_time on write to KVM system time MSR is a change of ABI. Probably only 2.6.16 based SLES 10 breaks due to its custom enhancements to kvmclock, but KVM never declared the MSR only for one-shot initialization. (Doc says that only one write is needed.) This reverts commit b7e60c5aedd2b63f16ef06fde4f81ca032211bc5. And adds a note to the definition of PVCLOCK_COUNTS_FROM_ZERO. Signed-off-by: Radim Krčmář <[email protected]> Acked-by: Marcelo Tosatti <[email protected]> Signed-off-by: Paolo Bonzini <[email protected]>
2015-09-28watchdog: iTCO: Fix dependencies on I2CGuenter Roeck1-1/+2
If I2C is built as module, the iTCO watchdog driver must be built as module as well. I2C_I801 must only be selected if I2C is configured. This fixes the following build errors, seen if I2C=m and ITCO_WDT=y. i2c-i801.c:(.text+0x2bf055): undefined reference to `i2c_del_adapter' i2c-i801.c:(.text+0x2c13e0): undefined reference to `i2c_add_adapter' i2c-i801.c:(.text+0x2c17bd): undefined reference to `i2c_new_device' Fixes: 2a7a0e9bf7b3 ("watchdog: iTCO_wdt: Add support for TCO on Intel Sunrisepoint") Reviewed-by: Matt Fleming <[email protected]> Cc: Lee Jones <[email protected]> Signed-off-by: Guenter Roeck <[email protected]> Signed-off-by: Wim Van Sebroeck <[email protected]>
2015-09-28watchdog: bcm2835: Fix poweroff behaviourNoralf Trønnes1-2/+8
Currently poweroff/halt results in a reboot on the Raspberry Pi. The firmware uses the RSTS register to know which partiton to boot from. The partiton value is spread into bits 0, 2, 4, 6, 8, 10. Partiton 63 is a special partition used by the firmware to indicate halt. The firmware made this change in 19 Aug 2013 and was matched by the downstream commit: Changes for new NOOBS multi partition booting from gsh Signed-off-by: Noralf Trønnes <[email protected]> Tested-by: Stephen Warren <[email protected]> Acked-by: Stephen Warren <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Signed-off-by: Wim Van Sebroeck <[email protected]>
2015-09-28watchdog: Fix module autoload for OF platform driverLuis de Bethencourt3-0/+3
These platform drivers have a OF device ID table but the OF module alias information is not created so module autoloading won't work. Signed-off-by: Luis de Bethencourt <[email protected]> Reviewed-by: Guenter Roeck <[email protected]> Signed-off-by: Wim Van Sebroeck <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.