- 24 Mar, 2018 40 commits
-
-
Boris Pismenny authored
commit 2c292dbb upstream. Add a check for the length of the qpin structure to prevent out-of-bounds reads BUG: KASAN: slab-out-of-bounds in create_raw_packet_qp+0x114c/0x15e2 Read of size 8192 at addr ffff880066b99290 by task syz-executor3/549 CPU: 3 PID: 549 Comm: syz-executor3 Not tainted 4.15.0-rc2+ #27 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014 Call Trace: dump_stack+0x8d/0xd4 print_address_description+0x73/0x290 kasan_report+0x25c/0x370 ? create_raw_packet_qp+0x114c/0x15e2 memcpy+0x1f/0x50 create_raw_packet_qp+0x114c/0x15e2 ? create_raw_packet_qp_tis.isra.28+0x13d/0x13d ? lock_acquire+0x370/0x370 create_qp_common+0x2245/0x3b50 ? destroy_qp_user.isra.47+0x100/0x100 ? kasan_kmalloc+0x13d/0x170 ? sched_clock_cpu+0x18/0x180 ? fs_reclaim_acquire.part.15+0x5/0x30 ? __lock_acquire+0xa11/0x1da0 ? sched_clock_cpu+0x18/0x180 ? kmem_cache_alloc_trace+0x17e/0x310 ? mlx5_ib_create_qp+0x30e/0x17b0 mlx5_ib_create_qp+0x33d/0x17b0 ? sched_clock_cpu+0x18/0x180 ? create_qp_common+0x3b50/0x3b50 ? lock_acquire+0x370/0x370 ? __radix_tree_lookup+0x180/0x220 ? uverbs_try_lock_object+0x68/0xc0 ? rdma_lookup_get_uobject+0x114/0x240 create_qp.isra.5+0xce4/0x1e20 ? ib_uverbs_ex_create_cq_cb+0xa0/0xa0 ? copy_ah_attr_from_uverbs.isra.2+0xa00/0xa00 ? ib_uverbs_cq_event_handler+0x160/0x160 ? __might_fault+0x17c/0x1c0 ib_uverbs_create_qp+0x21b/0x2a0 ? ib_uverbs_destroy_cq+0x2e0/0x2e0 ib_uverbs_write+0x55a/0xad0 ? ib_uverbs_destroy_cq+0x2e0/0x2e0 ? ib_uverbs_destroy_cq+0x2e0/0x2e0 ? ib_uverbs_open+0x760/0x760 ? futex_wake+0x147/0x410 ? check_prev_add+0x1680/0x1680 ? do_futex+0x3d3/0xa60 ? sched_clock_cpu+0x18/0x180 __vfs_write+0xf7/0x5c0 ? ib_uverbs_open+0x760/0x760 ? kernel_read+0x110/0x110 ? lock_acquire+0x370/0x370 ? __fget+0x264/0x3b0 vfs_write+0x18a/0x460 SyS_write+0xc7/0x1a0 ? SyS_read+0x1a0/0x1a0 ? trace_hardirqs_on_thunk+0x1a/0x1c entry_SYSCALL_64_fastpath+0x18/0x85 RIP: 0033:0x4477b9 RSP: 002b:00007f1822cadc18 EFLAGS: 00000292 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00000000004477b9 RDX: 0000000000000070 RSI: 000000002000a000 RDI: 0000000000000005 RBP: 0000000000708000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000292 R12: 00000000ffffffff R13: 0000000000005d70 R14: 00000000006e6e30 R15: 0000000020010ff0 Allocated by task 549: __kmalloc+0x15e/0x340 kvmalloc_node+0xa1/0xd0 create_user_qp.isra.46+0xd42/0x1610 create_qp_common+0x2e63/0x3b50 mlx5_ib_create_qp+0x33d/0x17b0 create_qp.isra.5+0xce4/0x1e20 ib_uverbs_create_qp+0x21b/0x2a0 ib_uverbs_write+0x55a/0xad0 __vfs_write+0xf7/0x5c0 vfs_write+0x18a/0x460 SyS_write+0xc7/0x1a0 entry_SYSCALL_64_fastpath+0x18/0x85 Freed by task 368: kfree+0xeb/0x2f0 kernfs_fop_release+0x140/0x180 __fput+0x266/0x700 task_work_run+0x104/0x180 exit_to_usermode_loop+0xf7/0x110 syscall_return_slowpath+0x298/0x370 entry_SYSCALL_64_fastpath+0x83/0x85 The buggy address belongs to the object at ffff880066b99180 which belongs to the cache kmalloc-512 of size 512 The buggy address is located 272 bytes inside of 512-byte region [ffff880066b99180, ffff880066b99380) The buggy address belongs to the page: page:000000006040eedd count:1 mapcount:0 mapping: (null) index:0x0 compound_mapcount: 0 flags: 0x4000000000008100(slab|head) raw: 4000000000008100 0000000000000000 0000000000000000 0000000180190019 raw: ffffea00019a7500 0000000b0000000b ffff88006c403080 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff880066b99180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff880066b99200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff880066b99280: 00 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc ^ ffff880066b99300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff880066b99380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc Cc: syzkaller <syzkaller@googlegroups.com> Fixes: 0fb2ed66 ("IB/mlx5: Add create and destroy functionality for Raw Packet QP") Signed-off-by:
Boris Pismenny <borisp@mellanox.com> Signed-off-by:
Leon Romanovsky <leon@kernel.org> Signed-off-by:
Doug Ledford <dledford@redhat.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Boris Pismenny authored
commit c2b37f76 upstream. This patch validates user provided input to prevent integer overflow due to integer manipulation in the mlx5_ib_create_srq function. Cc: syzkaller <syzkaller@googlegroups.com> Fixes: e126ba97 ("mlx5: Add driver for Mellanox Connect-IB adapters") Signed-off-by:
-
Sreekanth Reddy authored
commit c666d3be upstream. This patch finishes all outstanding SCSI IO commands (but not other commands, e.g., task management) in the shutdown and unload paths. It first waits for the commands to complete (this is done after setting 'ioc->remove_host = 1 ', which prevents new commands to be queued) then it flushes commands that might still be running. This avoids triggering error handling (e.g., abort command) for all commands possibly completed by the adapter after interrupts disabled. [mauricfo: introduced something in commit message.] Signed-off-by:
Sreekanth Reddy <sreekanth.reddy@broadcom.com> Tested-by:
Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com> Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> [mauricfo: backport to linux-4.14.y (a few updates to context lines)] Signed-off-by:
-
Mauricio Faria de Oliveira authored
commit 9ff549ff upstream. This patch adds checks for 'ioc->remove_host' in the SCSI error handlers, so not to access pointers/resources potentially freed in the PCI shutdown/module unload path. The error handlers may be invoked after shutdown/unload, depending on other components. This problem was observed with kexec on a system with a mpt3sas based adapter and an infiniband adapter which takes long enough to shutdown: The mpt3sas driver finished shutting down / disabled interrupt handling, thus some commands have not finished and timed out. Since the system was still running (waiting for the infiniband adapter to shutdown), the scsi error handler for task abort of mpt3sas was invoked, and hit an oops -- either in scsih_abort() because 'ioc->scsi_lookup' was NULL without commit dbec4c90 ("scsi: mpt3sas: lockless command submission"), or later up in scsih_host_reset() (with or without that commit), because it eventually called mpt3sas_base_get_iocstate(). After the above commit, the oops in scsih_abort() does not occur anymore (_scsih_scsi_lookup_find_by_scmd() is no longer called), but that commit is too big and out of the scope of linux-stable, where this patch might help, so still go for the changes. Also, this might help to prevent similar errors in the future, in case code changes and possibly tries to access freed stuff. Note the fix in scsih_host_reset() is still important anyway. Signed-off-by:
-
Vignesh R authored
[ Upstream commit d087f157 ] Register layout of a typical TPCC_EVT_MUX_M_N register is such that the lowest numbered event is at the lowest byte address and highest numbered event at highest byte address. But TPCC_EVT_MUX_60_63 register layout is different, in that the lowest numbered event is at the highest address and highest numbered event is at the lowest address. Therefore, modify ti_am335x_xbar_write() to handle TPCC_EVT_MUX_60_63 register accordingly. Signed-off-by:
Vignesh R <vigneshr@ti.com> Signed-off-by:
Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by:
Vinod Koul <vinod.koul@intel.com> Signed-off-by:
Sasha Levin <alexander.levin@microsoft.com> Signed-off-by:
-
Lars Persson authored
[ Upstream commit 6d6e71fe ] The IV size should not include the 32 bit counter. Because we had the IV size set as 16 the transform only worked when the IV input was zero padded. Fixes: a21eb94f ("crypto: axis - add ARTPEC-6/7 crypto accelerator driver") Signed-off-by:
Lars Persson <larper@axis.com> Signed-off-by:
Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by:
-
Sergej Sawazki authored
[ Upstream commit cdba9a4f ] This drivers probe fails due to a clock name collision if a clock named 'plla' or 'pllb' is already registered when registering this drivers internal plls. Fix it by renaming internal plls to avoid name collisions. Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Cc: Rabeeh Khoury <rabeeh@solid-run.com> Signed-off-by:
Sergej Sawazki <sergej@taudac.com> Signed-off-by:
Stephen Boyd <sboyd@codeaurora.org> Signed-off-by:
-
Lars-Peter Clausen authored
[ Upstream commit 063578dc ] If the nocount bit is set the divider is bypassed and the settings for the divider count should be ignored and a divider value of 1 should be assumed. Handle this correctly in the driver recalc_rate() callback. While the driver sets up the part so that the read back dividers values yield the correct result the power-on reset settings of the part might not reflect this and hence calling e.g. clk_get_rate() without prior calls to clk_set_rate() will yield the wrong result. Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Signed-off-by:
-
Stephen Boyd authored
[ Upstream commit f8f8f1d0 ] The orphan clocks reparent operation shouldn't touch the hardware if clocks are enabled, otherwise it may get a chance to disable a newly registered critical clock which triggers the warning below. Assuming we have two clocks: A and B, B is the parent of A. Clock A has flag: CLK_OPS_PARENT_ENABLE Clock B has flag: CLK_IS_CRITICAL Step 1: Clock A is registered, then it becomes orphan. Step 2: Clock B is registered. Before clock B reach the critical clock enable operation, orphan A will find the newly registered parent B and do reparent operation, then parent B will be finally disabled in __clk_set_parent_after() due to CLK_OPS_PARENT_ENABLE flag as there's still no users of B which will then trigger the following warning. WARNING: CPU: 0 PID: 0 at drivers/clk/clk.c:597 clk_core_disable+0xb4/0xe0 Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-rc1-00056-gdff1f66-dirty #1373 Hardware name: Generic DT based system Backtrace: [<c010c4bc>] (dump_backtrace) from [<c010c764>] (show_stack+0x18/0x1c) r6:600000d3 r5:00000000 r4:c0e26358 r3:00000000 [<c010c74c>] (show_stack) from [<c040599c>] (dump_stack+0xb4/0xe8) [<c04058e8>] (dump_stack) from [<c0125c94>] (__warn+0xd8/0x104) r10:c0c21cd0 r9:c048aa78 r8:00000255 r7:00000009 r6:c0c1cd90 r5:00000000 r4:00000000 r3:c0e01d34 [<c0125bbc>] (__warn) from [<c0125d74>] (warn_slowpath_null+0x28/0x30) r9:00000000 r8:ef00bf80 r7:c165ac4c r6:ef00bf80 r5:ef00bf80 r4:ef00bf80 [<c0125d4c>] (warn_slowpath_null) from [<c048aa78>] (clk_core_disable+0xb4/0xe0) [<c048a9c4>] (clk_core_disable) from [<c048be88>] (clk_core_disable_lock+0x20/0x2c) r4:000000d3 r3:c0e0af00 [<c048be68>] (clk_core_disable_lock) from [<c048c224>] (clk_core_disable_unprepare+0x14/0x28) r5:00000000 r4:ef00bf80 [<c048c210>] (clk_core_disable_unprepare) from [<c048c270>] (__clk_set_parent_after+0x38/0x54) r4:ef00bd80 r3:000010a0 [<c048c238>] (__clk_set_parent_after) from [<c048daa8>] (clk_register+0x4d0/0x648) r6:ef00d500 r5:ef00bf80 r4:ef00bd80 r3:ef00bfd4 [<c048d5d8>] (clk_register) from [<c048dc30>] (clk_hw_register+0x10/0x1c) r9:00000000 r8:00000003 r7:00000000 r6:00000824 r5:00000001 r4:ef00d500 [<c048dc20>] (clk_hw_register) from [<c048e698>] (_register_divider+0xcc/0x120) [<c048e5cc>] (_register_divider) from [<c048e730>] (clk_register_divider+0x44/0x54) r10:00000004 r9:00000003 r8:00000001 r7:00000000 r6:00000003 r5:00000001 r4:f0810030 [<c048e6ec>] (clk_register_divider) from [<c0d3ff58>] (imx7ulp_clocks_init+0x558/0xe98) r7:c0e296f8 r6:c165c808 r5:00000000 r4:c165c808 [<c0d3fa00>] (imx7ulp_clocks_init) from [<c0d24db0>] (of_clk_init+0x118/0x1e0) r10:00000001 r9:c0e01f68 r8:00000000 r7:c0e01f60 r6:ef7f8974 r5:ef0035c0 r4:00000006 [<c0d24c98>] (of_clk_init) from [<c0d04a50>] (time_init+0x2c/0x38) r10:efffed40 r9:c0d61a48 r8:c0e78000 r7:c0e07900 r6:ffffffff r5:c0e78000 r4:00000000 [<c0d04a24>] (time_init) from [<c0d00b8c>] (start_kernel+0x218/0x394) [<c0d00974>] (start_kernel) from [<6000807c>] (0x6000807c) r10:00000000 r9:410fc075 r8:6000406a r7:c0e0c930 r6:c0d61a44 r5:c0e07918 r4:c0e78294 We know that the clk isn't enabled with any sort of prepare_count here so we don't need to enable anything to prevent a race. And we're holding the prepare mutex so set_rate/set_parent can't race here either. Based on an earlier patch by Dong Aisheng. Fixes: fc8726a2 ("clk: core: support clocks which requires parents enable (part 2)") Cc: Michael Turquette <mturquette@baylibre.com> Cc: Shawn Guo <shawnguo@kernel.org> Reported-by:
Dong Aisheng <aisheng.dong@nxp.com> Signed-off-by:
-
Romain Izard authored
[ Upstream commit 960e1c4d ] Wait for the syncronization of all clocks when resuming, not only the UPLL clock. Do not use regmap_read_poll_timeout, as it will call BUG() when interrupts are masked, which is the case in here. Signed-off-by:
Romain Izard <romain.izard.pro@gmail.com> Acked-by:
Ludovic Desroches <ludovic.desroches@microchip.com> Acked-by:
Nicolas Ferre <nicolas.ferre@microchip.com> Acked-by:
Alexandre Belloni <alexandre.belloni@free-electrons.com> Signed-off-by:
-
Benjamin Coddington authored
[ Upstream commit 66282ec1 ] Clients must be able to read a file in order to execute it, and for pNFS that means the client needs to be able to perform a LAYOUTGET on the file. This behavior for executable-only files was added for OPEN in commit a043226b "nfsd4: permit read opens of executable-only files". This fixes up xfstests generic/126 on block/scsi layouts. Signed-off-by:
Benjamin Coddington <bcodding@redhat.com> Signed-off-by:
J. Bruce Fields <bfields@redhat.com> Signed-off-by:
-
Joel Stanley authored
[ Upstream commit e40ed274 ] Fixes a warning when building with W=1. All of the ASPEED device trees build without warnings now. Signed-off-by:
Joel Stanley <joel@jms.id.au> Signed-off-by:
-
Anton Vasilyev authored
[ Upstream commit 74482086 ] Debugfs file reset_stats is created with S_IRUSR permissions, but ocrdma_dbgfs_ops_read() doesn't support OCRDMA_RESET_STATS, whereas ocrdma_dbgfs_ops_write() supports only OCRDMA_RESET_STATS. The patch fixes misstype with permissions. Found by Linux Driver Verification project (linuxtesting.org). Signed-off-by:
Anton Vasilyev <vasilyev@ispras.ru> Acked-by:
Selvin Xavier <selvin.xavier@broadcom.com> Signed-off-by:
Jason Gunthorpe <jgg@mellanox.com> Signed-off-by:
-
James Smart authored
[ Upstream commit e06351a0 ] In the lpfc discovery engine, when as a nvme target, where the driver was performing mailbox io with the adapter for port login when a NVME PRLI is received from the host. Rather than queue and eventually get back to sending a response after the mailbox traffic, the driver rejected the io with an error response. Turns out this particular initiator didn't like the rejection values (unable to process command/command in progress) so it never attempted a retry of the PRLI. Thus the host never established nvme connectivity with the lpfc target. By changing the rejection values (to Logical Busy/nothing more), the initiator accepted the response and would retry the PRLI, resulting in nvme connectivity. Signed-off-by:
Dick Kennedy <dick.kennedy@broadcom.com> Signed-off-by:
James Smart <james.smart@broadcom.com> Reviewed-by:
Hannes Reinecke <hare@suse.com> Signed-off-by:
-
James Smart authored
[ Upstream commit 9de416ac ] When enabled for both SCSI and NVME support, and connected pt2pt to a SCSI only target, the driver nodelist entry for the remote port is left in PRLI_ISSUE state and no SCSI LUNs are discovered. Works fine if only configured for SCSI support. Error was due to some of the prli points still reflecting the need to send only 1 PRLI. On a lot of fabric configs, targets were NVME only, which meant the fabric-reported protocol attributes were only telling the driver one protocol or the other. Thus things worked fine. With pt2pt, the driver must send a PRLI for both protocols as there are no hints on what the target supports. Thus pt2pt targets were hitting the multiple PRLI issues. Complete the dual PRLI support. Track explicitly whether scsi (fcp) or nvme prli's have been sent. Accurately track protocol support detected on each node as reported by the fabric or probed by PRLI traffic. Signed-off-by:
-
Johan Hovold authored
[ Upstream commit 8804517e ] Fix child-node lookup during probe, which ended up searching the whole device tree depth-first starting at the parent rather than just matching on its children. Note that the original premature free of the parent node has already been fixed separately. Also note that this pattern of looking up the first child node with a given property is rare enough that a generic helper is probably not warranted. Fixes: c97c4090 ("soc: qcom: smsm: Add driver for Qualcomm SMSM") Fixes: 3e8b5541 ("soc: qcom: smsm: fix of_node refcnting problem") Cc: Bjorn Andersson <bjorn.andersson@linaro.org> Cc: Rob Clark <robdclark@gmail.com> Signed-off-by:
Johan Hovold <johan@kernel.org> Reviewed-by:
Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by:
Andy Gross <andy.gross@linaro.org> Signed-off-by:
-
Haishuang Yan authored
[ Upstream commit 50670b6e ] If md is NULL, tun_dst must be freed, otherwise it will cause memory leak. Fixes: 1a66a836 ("gre: add collect_md mode to ERSPAN tunnel") Cc: William Tu <u9012063@gmail.com> Signed-off-by:
Haishuang Yan <yanhaishuang@cmss.chinamobile.com> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Haishuang Yan authored
[ Upstream commit dd8d5b8c ] When erspan_rcv call return PACKET_REJECT, we shoudn't call ipgre_rcv to process packets again, instead send icmp unreachable message in error path. Fixes: 84e54fe0 ("gre: introduce native tunnel support for ERSPAN") Acked-by:
William Tu <u9012063@gmail.com> Cc: William Tu <u9012063@gmail.com> Signed-off-by:
-
Alexey Kodanev authored
[ Upstream commit 53c81e95 ] LTP/udp6_ipsec_vti tests fail when sending large UDP datagrams over ip6_vti that require fragmentation and the underlying device has an MTU smaller than 1500 plus some extra space for headers. This happens because ip6_vti, by default, sets MTU to ETH_DATA_LEN and not updating it depending on a destination address or link parameter. Further attempts to send UDP packets may succeed because pmtu gets updated on ICMPV6_PKT_TOOBIG in vti6_err(). In case the lower device has larger MTU size, e.g. 9000, ip6_vti works but not using the possible maximum size, output packets have 1500 limit. The above cases require manual MTU setup after ip6_vti creation. However ip_vti already updates MTU based on lower device with ip_tunnel_bind_dev(). Here is the example when the lower device MTU is set to 9000: # ip a sh ltp_ns_veth2 ltp_ns_veth2@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 ... inet 10.0.0.2/24 scope global ltp_ns_veth2 inet6 fd00::2/64 scope global # ip li add vti6 type vti6 local fd00::2 remote fd00::1 # ip li show vti6 vti6@NONE: <POINTOPOINT,NOARP> mtu 1500 ... link/tunnel6 fd00::2 peer fd00::1 After the patch: # ip li add vti6 type vti6 local fd00::2 remote fd00::1 # ip li show vti6 vti6@NONE: <POINTOPOINT,NOARP> mtu 8832 ... link/tunnel6 fd00::2 peer fd00::1 Reported-by:
Petr Vorel <pvorel@suse.cz> Signed-off-by:
Alexey Kodanev <alexey.kodanev@oracle.com> Signed-off-by:
-
Jerry Snitselaar authored
[ Upstream commit 72d54811 ] It is unlikely request_threaded_irq will fail, but if it does for some reason we should clear iommu->pr_irq in the error path. Also intel_svm_finish_prq shouldn't try to clean up the page request interrupt if pr_irq is 0. Without these, if request_threaded_irq were to fail the following occurs: fail with no fixes: [ 0.683147] ------------[ cut here ]------------ [ 0.683148] NULL pointer, cannot free irq [ 0.683158] WARNING: CPU: 1 PID: 1 at kernel/irq/irqdomain.c:1632 irq_domain_free_irqs+0x126/0x140 [ 0.683160] Modules linked in: [ 0.683163] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2 #3 [ 0.683165] Hardware name: /NUC7i3BNB, BIOS BNKBL357.86A.0036.2017.0105.1112 01/05/2017 [ 0.683168] RIP: 0010:irq_domain_free_irqs+0x126/0x140 [ 0.683169] RSP: 0000:ffffc90000037ce8 EFLAGS: 00010292 [ 0.683171] RAX: 000000000000001d RBX: ffff880276283c00 RCX: ffffffff81c5e5e8 [ 0.683172] RDX: 0000000000000001 RSI: 0000000000000096 RDI: 0000000000000246 [ 0.683174] RBP: ffff880276283c00 R08: 0000000000000000 R09: 000000000000023c [ 0.683175] R10: 0000000000000007 R11: 0000000000000000 R12: 000000000000007a [ 0.683176] R13: 0000000000000001 R14: 0000000000000000 R15: 0000010010000000 [ 0.683178] FS: 0000000000000000(0000) GS:ffff88027ec80000(0000) knlGS:0000000000000000 [ 0.683180] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.683181] CR2: 0000000000000000 CR3: 0000000001c09001 CR4: 00000000003606e0 [ 0.683182] Call Trace: [ 0.683189] intel_svm_finish_prq+0x3c/0x60 [ 0.683191] free_dmar_iommu+0x1ac/0x1b0 [ 0.683195] init_dmars+0xaaa/0xaea [ 0.683200] ? klist_next+0x19/0xc0 [ 0.683203] ? pci_do_find_bus+0x50/0x50 [ 0.683205] ? pci_get_dev_by_id+0x52/0x70 [ 0.683208] intel_iommu_init+0x498/0x5c7 [ 0.683211] pci_iommu_init+0x13/0x3c [ 0.683214] ? e820__memblock_setup+0x61/0x61 [ 0.683217] do_one_initcall+0x4d/0x1a0 [ 0.683220] kernel_init_freeable+0x186/0x20e [ 0.683222] ? set_debug_rodata+0x11/0x11 [ 0.683225] ? rest_init+0xb0/0xb0 [ 0.683226] kernel_init+0xa/0xff [ 0.683229] ret_from_fork+0x1f/0x30 [ 0.683259] Code: 89 ee 44 89 e7 e8 3b e8 ff ff 5b 5d 44 89 e7 44 89 ee 41 5c 41 5d 41 5e e9 a8 84 ff ff 48 c7 c7 a8 71 a7 81 31 c0 e8 6a d3 f9 ff <0f> ff 5b 5d 41 5c 41 5d 41 5 e c3 0f 1f 44 00 00 66 2e 0f 1f 84 [ 0.683285] ---[ end trace f7650e42792627ca ]--- with iommu->pr_irq = 0, but no check in intel_svm_finish_prq: [ 0.669561] ------------[ cut here ]------------ [ 0.669563] Trying to free already-free IRQ 0 [ 0.669573] WARNING: CPU: 3 PID: 1 at kernel/irq/manage.c:1546 __free_irq+0xa4/0x2c0 [ 0.669574] Modules linked in: [ 0.669577] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc2 #4 [ 0.669579] Hardware name: /NUC7i3BNB, BIOS BNKBL357.86A.0036.2017.0105.1112 01/05/2017 [ 0.669581] RIP: 0010:__free_irq+0xa4/0x2c0 [ 0.669582] RSP: 0000:ffffc90000037cc0 EFLAGS: 00010082 [ 0.669584] RAX: 0000000000000021 RBX: 0000000000000000 RCX: ffffffff81c5e5e8 [ 0.669585] RDX: 0000000000000001 RSI: 0000000000000086 RDI: 0000000000000046 [ 0.669587] RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000023c [ 0.669588] R10: 0000000000000007 R11: 0000000000000000 R12: ffff880276253960 [ 0.669589] R13: ffff8802762538a4 R14: ffff880276253800 R15: ffff880276283600 [ 0.669593] FS: 0000000000000000(0000) GS:ffff88027ed80000(0000) knlGS:0000000000000000 [ 0.669594] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 0.669596] CR2: 0000000000000000 CR3: 0000000001c09001 CR4: 00000000003606e0 [ 0.669602] Call Trace: [ 0.669616] free_irq+0x30/0x60 [ 0.669620] intel_svm_finish_prq+0x34/0x60 [ 0.669623] free_dmar_iommu+0x1ac/0x1b0 [ 0.669627] init_dmars+0xaaa/0xaea [ 0.669631] ? klist_next+0x19/0xc0 [ 0.669634] ? pci_do_find_bus+0x50/0x50 [ 0.669637] ? pci_get_dev_by_id+0x52/0x70 [ 0.669639] intel_iommu_init+0x498/0x5c7 [ 0.669642] pci_iommu_init+0x13/0x3c [ 0.669645] ? e820__memblock_setup+0x61/0x61 [ 0.669648] do_one_initcall+0x4d/0x1a0 [ 0.669651] kernel_init_freeable+0x186/0x20e [ 0.669653] ? set_debug_rodata+0x11/0x11 [ 0.669656] ? rest_init+0xb0/0xb0 [ 0.669658] kernel_init+0xa/0xff [ 0.669661] ret_from_fork+0x1f/0x30 [ 0.669662] Code: 7a 08 75 0e e9 c3 01 00 00 4c 39 7b 08 74 57 48 89 da 48 8b 5a 18 48 85 db 75 ee 89 ee 48 c7 c7 78 67 a7 81 31 c0 e8 4c 37 fa ff <0f> ff 48 8b 34 24 4c 89 ef e 8 0e 4c 68 00 49 8b 46 40 48 8b 80 [ 0.669688] ---[ end trace 58a470248700f2fc ]--- Cc: Alex Williamson <alex.williamson@redhat.com> Cc: Joerg Roedel <joro@8bytes.org> Cc: Ashok Raj <ashok.raj@intel.com> Signed-off-by:
Jerry Snitselaar <jsnitsel@redhat.com> Reviewed-by:
Ashok Raj <ashok.raj@intel.com> Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
-
Brian Norris authored
[ Upstream commit 5c9d8c4f ] We generally leave the GPIO clock disabled, unless an interrupt is requested or we're accessing IO registers. We forgot to do this for the ->get_direction() callback, which means we can sometimes [1] get incorrect results [2] from, e.g., /sys/kernel/debug/gpio. Enable the clock, so we get the right results! [1] Sometimes, because many systems have 1 or mor interrupt requested on each GPIO bank, so they always leave their clock on. [2] Incorrect, meaning the register returns 0, and so we interpret that as "input". Signed-off-by:
Brian Norris <briannorris@chromium.org> Reviewed-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Florian Fainelli authored
[ Upstream commit 981ed1bf ] In case a platform only defaults a "default" set of pins, but not a "sleep" set of pins, and this particular platform suspends and resumes in a way that the pin states are not preserved by the hardware, when we resume, we would call pinctrl_single_resume() -> pinctrl_force_default() -> pinctrl_select_state() and the first thing we do is check that the pins state is the same as before, and do nothing. In order to fix this, decouple the actual state change from pinctrl_select_state() and move it pinctrl_commit_state(), while keeping the p->state == state check in pinctrl_select_state() not to change the caller assumptions. pinctrl_force_sleep() and pinctrl_force_default() are updated to bypass the state check by calling pinctrl_commit_state(). [Linus Walleij] The forced pin control states are currently only used in some pin controller drivers that grab their own reference to their own pins. This is equal to the pin control hogs: pins taken by pin control devices since there are no corresponding device in the Linux device hierarchy, such as memory controller lines or unused GPIO lines, or GPIO lines that are used orthogonally from the GPIO subsystem but pincontrol-wise managed as hogs (non-strict mode, allowing simultaneous use by GPIO and pin control). For this case forcing the state from the drivers' suspend()/resume() callbacks makes sense and should semantically match the name of the function. Fixes: 6e5e959d ("pinctrl: API changes to support multiple states per device") Signed-off-by:
Florian Fainelli <f.fainelli@gmail.com> Reviewed-by:
Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by:
-
Mauro Carvalho Chehab authored
[ Upstream commit 4f6c1104 ] Two orthogonal changesets caused a breakage at a printk inside davinci. Commit a2d17962 ("[media] davinci: Switch from V4L2 OF to V4L2 fwnode") made davinci to use struct fwnode_handle instead of struct device_node. Commit 68d9c47b ("media: Convert to using %pOF instead of full_name") changed the printk to not use ->full_name, but, instead, to rely on %pOF. With both patches applied, the Kernel will do the wrong thing, as warned by smatch: drivers/media/platform/davinci/vpif_capture.c:1399 vpif_async_bound() error: '%pOF' expects argument of type 'struct device_node*', argument 5 has type 'void*' So, change the logic to actually print the device name that was obtained before the print logic. Fixes: 68d9c47b ("media: Convert to using %pOF instead of full_name") Fixes: a2d17962 ("[media] davinci: Switch from V4L2 OF to V4L2 fwnode") Signed-off-by:
Mauro Carvalho Chehab <mchehab@s-opensource.com> Acked-by:
Lad, Prabhakar <prabhakar.csengg@gmail.com> Signed-off-by:
-
Geert Uytterhoeven authored
[ Upstream commit 83c75ddd ] rcar_pcie_parse_request_of_pci_ranges() can fail and return an error code, but this is not checked nor handled. Fix this by adding the missing error handling. Fixes: 5d2917d4 ("PCI: rcar: Convert to DT resource parsing API") Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by:
Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by:
-
Niklas Cassel authored
[ Upstream commit 35ad6192 ] find_first_zero_bit()'s parameter 'size' is defined in bits, not in bytes. Calling find_first_zero_bit() with the wrong size unit will lead to insidious bugs. Fix this by calling find_first_zero_bit() with size BITS_PER_LONG, rather than sizeof() and add missing find_first_zero_bit() return handling. Fixes: d7467991 ("PCI: endpoint: Introduce configfs entry for configuring EP functions") Signed-off-by:
Niklas Cassel <niklas.cassel@axis.com> Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
-
Kishon Vijay Abraham I authored
[ Upstream commit a134a457 ] ->get_msi() now checks MSI_EN bit in the MSI CAPABILITY register to find whether the host supports MSI instead of using the MSI ADDRESS in the MSI CAPABILITY register. This fixes the issue with the following sequence 'modprobe pci_endpoint_test' enables MSI 'rmmod pci_endpoint_test' disables MSI but MSI address (in EP's capability register) has a valid value 'modprobe pci_endpoint_test no_msi=1' - Since MSI address (in EP's capability register) has a valid value (set during the previous insertion of the module), EP thinks host supports MSI. Fixes: f8aed6ec ("PCI: dwc: designware: Add EP mode support") Signed-off-by:
-
Robert Walker authored
[ Upstream commit 11595db8 ] The CoreSight TPIU should be disabled when tracing to other sinks to allow them to operate at full bandwidth. This patch fixes tpiu_disable_hw() to correctly disable the TPIU by configuring the TPIU to stop on flush, initiating a manual flush, waiting for the flush to complete and then waits for the TPIU to indicate it has stopped. Signed-off-by:
Robert Walker <robert.walker@arm.com> Tested-by:
Mike Leach <mike.leach@linaro.org> Signed-off-by:
Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by:
-
Sahara authored
[ Upstream commit 2b022ab7 ] In case that CONFIG_SLUB_DEBUG is on and pty is used, races between release_one_tty and flush_to_ldisc work threads may happen and lead to use-after-free condition on tty->link->port. Because SLUB_DEBUG is turned on, freed tty->link->port is filled with POISON_FREE value. So far without SLUB_DEBUG, port was filled with zero and flush_to_ldisc could return without a problem by checking if tty is NULL. CPU 0 CPU 1 ----- ----- release_tty pty_write cancel_work_sync(tty) to = tty->link tty_kref_put(tty->link) tty_schedule_flip(to->port) << workqueue >> ... release_one_tty ... pty_cleanup ... kfree(tty->link->port) << workqueue >> flush_to_ldisc tty = READ_ONCE(port->itty) tty is 0x6b6b6b6b6b6b6b6b !!PANIC!! access tty->ldisc Unable to handle kernel paging request at virtual address 6b6b6b6b6b6b6b93 pgd = ffffffc0eb1c3000 [6b6b6b6b6b6b6b93] *pgd=0000000000000000, *pud=0000000000000000 ------------[ cut here ]------------ Kernel BUG at ffffff800851154c [verbose debug info unavailable] Internal error: Oops - BUG: 96000004 [#1] PREEMPT SMP CPU: 3 PID: 265 Comm: kworker/u8:9 Tainted: G W 3.18.31-g0a58eeb #1 Hardware name: Qualcomm Technologies, Inc. MSM 8996pro v1.1 + PMI8996 Carbide (DT) Workqueue: events_unbound flush_to_ldisc task: ffffffc0ed610ec0 ti: ffffffc0ed624000 task.ti: ffffffc0ed624000 PC is at ldsem_down_read_trylock+0x0/0x4c LR is at tty_ldisc_ref+0x24/0x4c pc : [<ffffff800851154c>] lr : [<ffffff800850f6c0>] pstate: 80400145 sp : ffffffc0ed627cd0 x29: ffffffc0ed627cd0 x28: 0000000000000000 x27: ffffff8009e05000 x26: ffffffc0d382cfa0 x25: 0000000000000000 x24: ffffff800a012f08 x23: 0000000000000000 x22: ffffffc0703fbc88 x21: 6b6b6b6b6b6b6b6b x20: 6b6b6b6b6b6b6b93 x19: 0000000000000000 x18: 0000000000000001 x17: 00e80000f80d6f53 x16: 0000000000000001 x15: 0000007f7d826fff x14: 00000000000000a0 x13: 0000000000000000 x12: 0000000000000109 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffffc0ed624000 x8 : ffffffc0ed611580 x7 : 0000000000000000 x6 : ffffff800a42e000 x5 : 00000000000003fc x4 : 0000000003bd1201 x3 : 0000000000000001 x2 : 0000000000000001 x1 : ffffff800851004c x0 : 6b6b6b6b6b6b6b93 Signed-off-by:
Sahara <keun-o.park@darkmatter.ae> Signed-off-by:
-
Peter Ujfalusi authored
[ Upstream commit b7ea6b28 ] Check the status of the DMM engine after it is reported that the transaction was completed as in rare cases the engine might not reached a working state. The wait_status() will print information in case the DMM is not reached the expected state and the dmm_txn_commit() will return with an error code to make sure that we are not continuing with a broken setup. Signed-off-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
Zhoujie Wu authored
[ Upstream commit 8d876bf4 ] According to SD spec 3.00 3.6.1 signal voltage switch procedure step 6~8, (6) Set 1.8V Signal Enable in the Host Control 2 register. (7) Wait 5ms. 1.8V voltage regulator shall be stable within this period. (8) If 1.8V Signal Enable is cleared by Host Controller, go to step (12). Host should wait 5ms after set 1.8V signal enable bit in Host Control 2 register and check if 1.8V is stable or not. But current code checks this bit right after set it. On some platforms with xenon controller found the bit is cleared right away and host reports "1.8V regulator output did not became stable" and 5ms delay can help. Implement voltage_switch callback for xenon controller to add 5ms delay to make sure the 1.8V signal enable bit is set by controller. Signed-off-by:
Zhoujie Wu <zjwu@marvell.com> Acked-by:
Adrian Hunter <adrian.hunter@intel.com> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
H. Nikolaus Schaller authored
[ Upstream commit c1b9d4c7 ] The vendor name was "toppoly" but other panels and the vendor list have defined it as "tpo". So let's fix it in driver and bindings. We keep the old definition in parallel to stay compatible with potential older DTB setup. Signed-off-by:
H. Nikolaus Schaller <hns@goldelico.com> Signed-off-by:
-
Bjorn Helgaas authored
[ Upstream commit c8208411 ] Set the resource type when we reserve VGA-related I/O port resources. The resource code doesn't actually look at the type, so it inserts resources without a type in the tree correctly even without this change. But if we ever print a resource without a type, it looks like this: vga+ [??? 0x000003c0-0x000003df flags 0x0] Setting the type means it will be printed correctly as: vga+ [io 0x000003c0-0x000003df] Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Signed-off-by:
-
Bharat Potnuri authored
[ Upstream commit 66f53e6f ] isert commands that failed during isert_rdma_rw_ctx_post() are queued to Queue-Full(QF) queue and are scheduled to be reposted during queue-full queue processing. During this reposting, the rdma contexts are initialised again in isert_rdma_rw_ctx_post(), which is leaking significant memory. unreferenced object 0xffff8830201d9640 (size 64): comm "kworker/0:2", pid 195, jiffies 4295374851 (age 4528.436s) hex dump (first 32 bytes): 00 60 8b cb 2e 00 00 00 00 10 00 00 00 00 00 00 .`.............. 00 90 e3 cb 2e 00 00 00 00 10 00 00 00 00 00 00 ................ backtrace: [<ffffffff8170711e>] kmemleak_alloc+0x4e/0xb0 [<ffffffff811f8ba5>] __kmalloc+0x125/0x2b0 [<ffffffffa046b24f>] rdma_rw_ctx_init+0x15f/0x6f0 [ib_core] [<ffffffffa07ab644>] isert_rdma_rw_ctx_post+0xc4/0x3c0 [ib_isert] [<ffffffffa07ad972>] isert_put_datain+0x112/0x1c0 [ib_isert] [<ffffffffa07dddce>] lio_queue_data_in+0x2e/0x30 [iscsi_target_mod] [<ffffffffa076c322>] target_qf_do_work+0x2b2/0x4b0 [target_core_mod] [<ffffffff81080c3b>] process_one_work+0x1db/0x5d0 [<ffffffff8108107d>] worker_thread+0x4d/0x3e0 [<ffffffff81088667>] kthread+0x117/0x150 [<ffffffff81713fa7>] ret_from_fork+0x27/0x40 [<ffffffffffffffff>] 0xffffffffffffffff Here is patch to use the older rdma contexts while reposting the isert commands intead of reinitialising them. Signed-off-by:
Potnuri Bharat Teja <bharat@chelsio.com> Reviewed-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
-
Artemy Kovalyov authored
[ Upstream commit edf1a84f ] In ib_umem structure npages holds original number of sg entries, while nmap is number of DMA blocks returned by dma_map_sg. Fixes: c5d76f13 ('IB/core: Add umem function to read data from user-space') Signed-off-by:
Artemy Kovalyov <artemyko@mellanox.com> Signed-off-by:
-
Parav Pandit authored
[ Upstream commit 7baaa49a ] The code was using the src size when formatting the dst. They are almost certainly the same value but it reads wrong. Fixes: ce117ffa ("RDMA/cma: Export AF_IB statistics") Signed-off-by:
Parav Pandit <parav@mellanox.com> Reviewed-by:
Daniel Jurgens <danielj@mellanox.com> Signed-off-by:
-
Erez Shitrit authored
[ Upstream commit 43900089 ] The ipoib path database is organized around DGIDs from the LLADDR, but the SA is free to return a different GID when asked for path. This causes a bug because the SA's modified DGID is copied into the database key, even though it is no longer the correct lookup key, causing a memory leak and other malfunctions. Ensure the database key does not change after the SA query completes. Demonstration of the bug is as follows ipoib wants to send to GID fe80:0000:0000:0000:0002:c903:00ef:5ee2, it creates new record in the DB with that gid as a key, and issues a new request to the SM. Now, the SM from some reason returns path-record with other SGID (for example, 2001:0000:0000:0000:0002:c903:00ef:5ee2 that contains the local subnet prefix) now ipoib will overwrite the current entry with the new one, and if new request to the original GID arrives ipoib will not find it in the DB (was overwritten) and will create new record that in its turn will also be overwritten by the response from the SM, and so on till the driver eats all the device memory. Signed-off-by:
Erez Shitrit <erezsh@mellanox.com> Signed-off-by:
-
Alexandre Belloni authored
[ Upstream commit 994ec64c ] The probe function is not allowed to fail after registering the RTC because the following may happen: CPU0: CPU1: sys_load_module() do_init_module() do_one_initcall() cmos_do_probe() rtc_device_register() __register_chrdev() cdev->owner = struct module* open("/dev/rtc0") rtc_device_unregister() module_put() free_module() module_free(mod->module_core) /* struct module *module is now freed */ chrdev_open() spin_lock(cdev_lock) cdev_get() try_module_get() module_is_live() /* dereferences already freed struct module* */ Also, the interrupt handler: ac100_rtc_irq() is dereferencing chip->rtc but this may still be NULL when it is called, resulting in: Unable to handle kernel NULL pointer dereference at virtual address 00000194 pgd = (ptrval) [00000194] *pgd=00000000 Internal error: Oops: 5 [#1] SMP ARM Modules linked in: CPU: 0 PID: 72 Comm: irq/71-ac100-rt Not tainted 4.15.0-rc1-next-20171201-dirty #120 Hardware name: Allwinner sun8i Family task: (ptrval) task.stack: (ptrval) PC is at mutex_lock+0x14/0x3c LR is at ac100_rtc_irq+0x38/0xc8 pc : [<c06543a4>] lr : [<c04d9a2c>] psr: 60000053 sp : ee9c9f28 ip : 00000000 fp : ee9adfdc r10: 00000000 r9 : c0a04c48 r8 : c015ed18 r7 : ee9bd600 r6 : ee9c9f28 r5 : ee9af590 r4 : c0a04c48 r3 : ef3cb3c0 r2 : 00000000 r1 : ee9af590 r0 : 00000194 Flags: nZCv IRQs on FIQs off Mode SVC_32 ISA ARM Segment none Control: 10c5387d Table: 4000406a DAC: 00000051 Process irq/71-ac100-rt (pid: 72, stack limit = 0x(ptrval)) Stack: (0xee9c9f28 to 0xee9ca000) 9f20: 00000000 7c2fd1be c015ed18 ee9adf40 ee9c0400 ee9c0400 9f40: ee9adf40 c015ed34 ee9c8000 ee9adf64 ee9c0400 c015f040 ee9adf80 00000000 9f60: c015ee24 7c2fd1be ee9adfc0 ee9adf80 00000000 ee9c8000 ee9adf40 c015eef4 9f80: ef1eba34 c0138f14 ee9c8000 ee9adf80 c0138df4 00000000 00000000 00000000 9fa0: 00000000 00000000 00000000 c01010e8 00000000 00000000 00000000 00000000 9fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 9fe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffffffff ffffffff [<c06543a4>] (mutex_lock) from [<c04d9a2c>] (ac100_rtc_irq+0x38/0xc8) [<c04d9a2c>] (ac100_rtc_irq) from [<c015ed34>] (irq_thread_fn+0x1c/0x54) [<c015ed34>] (irq_thread_fn) from [<c015f040>] (irq_thread+0x14c/0x214) [<c015f040>] (irq_thread) from [<c0138f14>] (kthread+0x120/0x150) [<c0138f14>] (kthread) from [<c01010e8>] (ret_from_fork+0x14/0x2c) Solve both issues by moving to devm_rtc_allocate_device()/rtc_register_device() Reported-by:
Quentin Schulz <quentin.schulz@free-electrons.com> Tested-by:
-
Shuah Khan authored
[ Upstream commit f45ce987 ] Driver calls request_firmware() whenever the device is opened for the first time. As the device gets opened and closed, dev->num_inst == 1 is true several times. This is not necessary since the firmware is saved in the fw_buf. s5p_mfc_load_firmware() copies the buffer returned by the request_firmware() to dev->fw_buf. fw_buf sticks around until it gets released from s5p_mfc_remove(), hence there is no need to keep requesting firmware and copying it to fw_buf. This might have been overlooked when changes are made to free fw_buf from the device release interface s5p_mfc_release(). Fix s5p_mfc_load_firmware() to call request_firmware() once and keep state. Change _probe() to load firmware once fw_buf has been allocated. s5p_mfc_open() and it continues to call s5p_mfc_load_firmware() and init hardware which is the step where firmware is written to the device. This addresses the mfc_mutex contention due to repeated request_firmware() calls from open() in the following circular locking warning: [ 552.194115] qtdemux0:sink/2710 is trying to acquire lock: [ 552.199488] (&dev->mfc_mutex){+.+.}, at: [<bf145544>] s5p_mfc_mmap+0x28/0xd4 [s5p_mfc] [ 552.207459] but task is already holding lock: [ 552.213264] (&mm->mmap_sem){++++}, at: [<c01df2e4>] vm_mmap_pgoff+0x44/0xb8 [ 552.220284] which lock already depends on the new lock. [ 552.228429] the existing dependency chain (in reverse order) is: [ 552.235881] -> #2 (&mm->mmap_sem){++++}: [ 552.241259] __might_fault+0x80/0xb0 [ 552.245331] filldir64+0xc0/0x2f8 [ 552.249144] call_filldir+0xb0/0x14c [ 552.253214] ext4_readdir+0x768/0x90c [ 552.257374] iterate_dir+0x74/0x168 [ 552.261360] SyS_getdents64+0x7c/0x1a0 [ 552.265608] ret_fast_syscall+0x0/0x28 [ 552.269850] -> #1 (&type->i_mutex_dir_key#2){++++}: [ 552.276180] down_read+0x48/0x90 [ 552.279904] lookup_slow+0x74/0x178 [ 552.283889] walk_component+0x1a4/0x2e4 [ 552.288222] link_path_walk+0x174/0x4a0 [ 552.292555] path_openat+0x68/0x944 [ 552.296541] do_filp_open+0x60/0xc4 [ 552.300528] file_open_name+0xe4/0x114 [ 552.304772] filp_open+0x28/0x48 [ 552.308499] kernel_read_file_from_path+0x30/0x78 [ 552.313700] _request_firmware+0x3ec/0x78c [ 552.318291] request_firmware+0x3c/0x54 [ 552.322642] s5p_mfc_load_firmware+0x54/0x150 [s5p_mfc] [ 552.328358] s5p_mfc_open+0x4e4/0x550 [s5p_mfc] [ 552.333394] v4l2_open+0xa0/0x104 [videodev] [ 552.338137] chrdev_open+0xa4/0x18c [ 552.342121] do_dentry_open+0x208/0x310 [ 552.346454] path_openat+0x28c/0x944 [ 552.350526] do_filp_open+0x60/0xc4 [ 552.354512] do_sys_open+0x118/0x1c8 [ 552.358586] ret_fast_syscall+0x0/0x28 [ 552.362830] -> #0 (&dev->mfc_mutex){+.+.}: -> #0 (&dev->mfc_mutex){+.+.}: [ 552.368379] lock_acquire+0x6c/0x88 [ 552.372364] __mutex_lock+0x68/0xa34 [ 552.376437] mutex_lock_interruptible_nested+0x1c/0x24 [ 552.382086] s5p_mfc_mmap+0x28/0xd4 [s5p_mfc] [ 552.386939] v4l2_mmap+0x54/0x88 [videodev] [ 552.391601] mmap_region+0x3a8/0x638 [ 552.395673] do_mmap+0x330/0x3a4 [ 552.399400] vm_mmap_pgoff+0x90/0xb8 [ 552.403472] SyS_mmap_pgoff+0x90/0xc0 [ 552.407632] ret_fast_syscall+0x0/0x28 [ 552.411876] other info that might help us debug this: [ 552.419848] Chain exists of: &dev->mfc_mutex --> &type->i_mutex_dir_key#2 --> &mm->mmap_sem [ 552.431200] Possible unsafe locking scenario: [ 552.437092] CPU0 CPU1 [ 552.441598] ---- ---- [ 552.446104] lock(&mm->mmap_sem); [ 552.449484] lock(&type->i_mutex_dir_key#2); [ 552.456329] lock(&mm->mmap_sem); [ 552.462222] lock(&dev->mfc_mutex); [ 552.465775] *** DEADLOCK *** Signed-off-by:
Shuah Khan <shuahkh@osg.samsung.com> Signed-off-by:
Sylwester Nawrocki <s.nawrocki@samsung.com> Signed-off-by:
-
Russell King authored
[ Upstream commit 20b56ed9 ] The detection of a PHY changed in commit e98a3aab ("mdio_bus: don't return NULL from mdiobus_scan()") which now causes sfp to print an error message. Update for this change. Fixes: 73970055 ("sfp: add SFP module support") Signed-off-by:
Russell King <rmk+kernel@armlinux.org.uk> Signed-off-by:
-
Russell King authored
[ Upstream commit 2794ffc4 ] The EEPROM reading was trying to read from the second EEPROM address if we requested the last byte from the SFF8079 EEPROM, which caused a failure when the second EEPROM is not present. Discovered with a S-RJ01 SFP module. Fix this. Fixes: 73970055 ("sfp: add SFP module support") Signed-off-by:
-
