Select Git revision
Search by author
- Any Author
- authors
-
Alessandro Pecugi alessandro.pecugi
-
Andrea Da Col
andrea.dacol
-
Andrii Sosiuk
andrii.sosiuk
-
Carlo Ferriolo carlo.ferriolo
-
Christian Stimming
christian.stimming
-
Christos Karampeazis
-
CI Variables Management Service Account service_account_ci_vars_management
-
Costanza Vasai costanza.vasai
-
Daniel Rinaldi daniel.rinaldi
-
Davide Cardillo
davide.cardillo
-
Dietmar Muscholik dietmar.muscholik
-
Dmitry Petrov dmitry.petrov
-
Elias Radi elias.radi
-
Ettore Chimenti
ektor5
-
Fabio Falsini
fabio.falsini
-
Fabrizio Benvenuti fabrizio.benvenuti
-
Felix Gerking felix.gerking
-
Gianfranco Mariotti
gianfranco.mariotti
-
GitBot
gitbot
-
Git Bot Service Account
service_account_gitbot
- May 14, 2021
-
-
Elad Grupi authored
[ Upstream commit bdaf1327 ] In case there is an io that contains inline data and it goes to parsing error flow, command response will free command and iov before clearing the data on the socket buffer. This will delay the command response until receive flow is completed. Fixes: 872d26a3 ("nvmet-tcp: add NVMe over TCP target driver") Signed-off-by:
Elad Grupi <elad.grupi@dell.com> Signed-off-by:
Hou Pu <houpu.main@gmail.com> Reviewed-by:
Sagi Grimberg <sagi@grimberg.me> Signed-off-by:
Christoph Hellwig <hch@lst.de> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Fabrice Gasnier authored
[ Upstream commit 4917e498 ] The ARR register is cleared unconditionally upon probing, after the maximum value has been read. This initial condition is rather not intuitive, when considering the counter child driver. It rather expects the maximum value by default: - The counter interface shows a zero value by default for 'ceiling' attribute. - Enabling the counter without any prior configuration makes it doesn't count. The reset value of ARR register is the maximum. So Choice here is to backup it, and restore it then, instead of clearing its value. It also fixes the initial condition seen by the counter driver. Fixes: d0f949e2 ("mfd: Add STM32 Timers driver") Signed-off-by:
Fabrice Gasnier <fabrice.gasnier@foss.st.com> Acked-by:
William Breathitt Gray <vilhelm.gray@gmail.com> Signed-off-by:
Lee Jones <lee.jones@linaro.org> Signed-off-by:
-
Orson Zhai authored
[ Upstream commit 9468ab84 ] Unisoc mailbox has no way to be enabled/disabled for any single channel. They can only be set to startup or shutdown as a whole device at same time. Add a variable to count references to avoid mailbox FIFO being reset unexpectedly when clients are requesting or freeing channels. Also add a lock to dismiss possible conflicts from register r/w in different startup or shutdown threads. And fix the crash problem when early interrupts come from channel which has not been requested by client yet. Fixes: ca27fc26 ("mailbox: sprd: Add Spreadtrum mailbox driver") Signed-off-by:
Orson Zhai <orson.zhai@unisoc.com> Reviewed-by:
Baolin Wang <baolin.wang7@gmail.com> Signed-off-by:
Jassi Brar <jaswinder.singh@linaro.org> Signed-off-by:
-
Brian King authored
[ Upstream commit 15cfef86 ] This fixes an issue hitting the BUG_ON() in ibmvfc_do_work(). When going through a host action of IBMVFC_HOST_ACTION_RESET, we change the action to IBMVFC_HOST_ACTION_TGT_DEL, then drop the host lock, and reset the CRQ, which changes the host state to IBMVFC_NO_CRQ. If, prior to setting the host state to IBMVFC_NO_CRQ, ibmvfc_init_host() is called, it can then end up changing the host action to IBMVFC_HOST_ACTION_INIT. If we then change the host state to IBMVFC_NO_CRQ, we will then hit the BUG_ON(). Make a couple of changes to avoid this. Leave the host action to be IBMVFC_HOST_ACTION_RESET or IBMVFC_HOST_ACTION_REENABLE until after we drop the host lock and reset or reenable the CRQ. Also harden the host state machine to ensure we cannot leave the reset / reenable state until we've finished processing the reset or reenable. Link: https://lore.kernel.org/r/20210413001009.902400-1-tyreld@linux.ibm.com Fixes: 73ee5d86 ("[SCSI] ibmvfc: Fix soft lockup on resume") Signed-off-by:
Brian King <brking@linux.vnet.ibm.com> [tyreld: added fixes tag] Signed-off-by:
Tyrel Datwyler <tyreld@linux.ibm.com> [mkp: fix comment checkpatch warnings] Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Sergey Shtylyov authored
[ Upstream commit 1160d61b ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to request_irq() (which takes *unsigned* IRQ #s), causing it to fail with -EINVAL (overridden by -ENODEV further below). Stop calling request_irq() with the invalid IRQ #s. Link: https://lore.kernel.org/r/8f4b8fa5-8251-b977-70a1-9099bcb4bb17@omprussia.ru Fixes: c27d85f3 ("[SCSI] SNI RM 53c710 driver") Signed-off-by:
Sergey Shtylyov <s.shtylyov@omprussia.ru> Signed-off-by:
-
Sergey Shtylyov authored
[ Upstream commit 14b32138 ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding the real error code. Stop calling request_irq() with the invalid IRQ #s. Link: https://lore.kernel.org/r/363eb4c8-a3bf-4dc9-2a9e-90f349030a15@omprussia.ru Fixes: 0bb67f18 ("[SCSI] sun3x_esp: convert to esp_scsi") Signed-off-by:
-
Sergey Shtylyov authored
[ Upstream commit 38fca15c ] The driver neglects to check the result of platform_get_irq()'s call and blithely passes the negative error codes to request_irq() (which takes *unsigned* IRQ #), causing it to fail with -EINVAL, overriding the real error code. Stop calling request_irq() with the invalid IRQ #s. Link: https://lore.kernel.org/r/594aa9ae-2215-49f6-f73c-33bd38989912@omprussia.ru Fixes: 352e921f ("[SCSI] jazz_esp: converted to use esp_core") Signed-off-by:
-
Sergey Shtylyov authored
[ Upstream commit 6c11dc06 ] Commit df2d8213 ("hisi_sas: use platform_get_irq()") failed to take into account that irq_of_parse_and_map() and platform_get_irq() have a different way of indicating an error: the former returns 0 and the latter returns a negative error code. Fix up the IRQ checks! Link: https://lore.kernel.org/r/810f26d3-908b-1d6b-dc5c-40019726baca@omprussia.ru Fixes: df2d8213 ("hisi_sas: use platform_get_irq()") Acked-by:
John Garry <john.garry@huawei.com> Signed-off-by:
-
Sergey Shtylyov authored
[ Upstream commit 339c9b63 ] The driver overrides the error codes returned by platform_get_irq() to -ENODEV, so if it returns -EPROBE_DEFER, the driver would fail the probe permanently instead of the deferred probing. Propagate the error code upstream as it should have been done from the start... Link: https://lore.kernel.org/r/420364ca-614a-45e3-4e35-0e0653c7bc53@omprussia.ru Fixes: 2953f850 ("[SCSI] ufs: use devres functions for ufshcd") Signed-off-by:
-
Colin Ian King authored
[ Upstream commit 40fa7394 ] The for-loop iterates with a u8 loop counter i and compares this with the loop upper limit of pm8001_ha->max_q_num which is a u32 type. There is a potential infinite loop if pm8001_ha->max_q_num is larger than the u8 loop counter. Fix this by making the loop counter the same type as pm8001_ha->max_q_num. [mkp: this is purely theoretical, max_q_num is currently limited to 64] Link: https://lore.kernel.org/r/20210407135840.494747-1-colin.king@canonical.com Fixes: 65df7d19 ("scsi: pm80xx: Fix chip initialization failure") Addresses-Coverity: ("Infinite loop") Reviewed-by:
Johannes Thumshirn <johannes.thumshirn@wdc.com> Signed-off-by:
Colin Ian King <colin.king@canonical.com> Signed-off-by:
-
Igor Pylypiv authored
[ Upstream commit 3f744a14 ] The mpi_uninit_check() takes longer for inbound doorbell register to be cleared. Increase the timeout substantially so that the driver does not fail to load. Previously, the inbound doorbell wait time was mistakenly increased in the mpi_init_check() instead of mpi_uninit_check(). It is okay to leave the mpi_init_check() wait time as-is as these are timeout values and if there is a failure, waiting longer is not an issue. Link: https://lore.kernel.org/r/20210406180534.1924345-2-ipylypiv@google.com Fixes: e90e2362 ("scsi: pm80xx: Increase timeout for pm80xx mpi_uninit_check") Reviewed-by:
Vishakha Channapattan <vishakhavc@google.com> Acked-by:
Jack Wang <jinpu.wang@ionos.com> Signed-off-by:
Igor Pylypiv <ipylypiv@google.com> Signed-off-by:
-
Colin Ian King authored
[ Upstream commit f6b1340d ] The for-loop iterates with a u8 loop counter i and compares this with the loop upper limit of num_parents that is an int type. There is a potential infinite loop if num_parents is larger than the u8 loop counter. Fix this by making the loop counter the same type as num_parents. Also make num_parents an unsigned int to match the return type of the call to clk_hw_get_num_parents. Addresses-Coverity: ("Infinite loop") Fixes: 734d82f4 ("clk: uniphier: add core support code for UniPhier clock driver") Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Link: https://lore.kernel.org/r/20210409090104.629722-1-colin.king@canonical.com Signed-off-by:
Stephen Boyd <sboyd@kernel.org> Signed-off-by:
-
Yingjie Wang authored
[ Upstream commit 25315ebf ] In radeon_dp_mst_detect(), We should check whether or not @connector has been unregistered from userspace. If the connector is unregistered, we should return disconnected status. Fixes: 9843ead0 ("drm/radeon: add DisplayPort MST support (v2)") Signed-off-by:
Yingjie Wang <wangyingjie55@126.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Nirmoy Das authored
[ Upstream commit 3bb11050 ] Replace GFP_KERNEL with GFP_ATOMIC as dcn20_resource_construct() can't sleep. Partially fixes: https://bugzilla.kernel.org/show_bug.cgi?id=212311 as dcn20_resource_construct() also calls into SMU functions which does mutex_lock(). Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
Nirmoy Das <nirmoy.das@amd.com> Signed-off-by:
-
Chen Hui authored
[ Upstream commit d0a859ed ] CONFIG_IPQ_APSS_PLL is tristate option and therefore this driver can be compiled as a module. This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Fixes: ecd2bacf ("clk: qcom: Add ipq apss pll driver") Signed-off-by:
Chen Hui <clare.chenhui@huawei.com> Reviewed-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Link: https://lore.kernel.org/r/20210409082352.233810-4-clare.chenhui@huawei.com Signed-off-by:
-
Chen Hui authored
[ Upstream commit 790b516a ] CONFIG_QCOM_A53PLL is tristate option and therefore this driver can be compiled as a module. This patch adds missing MODULE_DEVICE_TABLE definition which generates correct modalias for automatic loading of this driver when it is built as an external module. Fixes: 0c6ab1b8 ("clk: qcom: Add A53 PLL support") Signed-off-by:
-
Dan Carpenter authored
[ Upstream commit 5842ab76 ] The dp->train_set[] for this driver is only two characters, not four so this memsets too much. Fortunately, this ends up corrupting a struct hole and not anything important. Fixes: d76271d2 ("drm: xlnx: DRM/KMS driver for Xilinx ZynqMP DisplayPort Subsystem") Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
Michal Simek <michal.simek@xilinx.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/YGLwCBMotnrKZu6P@mwanda Signed-off-by:
-
Quanyang Wang authored
[ Upstream commit 394cdb69 ] If there is a IOCTL_SET_PLL_FRAC_MODE request sent to ATF ever, we shouldn't skip invoking PM_CLOCK_ENABLE fn even though this pll has been enabled. In ATF implementation, it will only assign the mode to the variable (struct pm_pll *)pll->mode when handling IOCTL_SET_PLL_FRAC_MODE call. Invoking PM_CLOCK_ENABLE can force ATF send request to PWU to set the pll mode to PLL's register. There is a scenario that happens in enabling VPLL_INT(clk_id:96): 1) VPLL_INT has been enabled during booting. 2) A driver calls clk_set_rate and according to the rate, the VPLL_INT should be set to FRAC mode. Then zynqmp_pll_set_mode is called to pass IOCTL_SET_PLL_FRAC_MODE to ATF. Note that at this point ATF just stores the mode to a variable. 3) This driver calls clk_prepare_enable and zynqmp_pll_enable is called to try to enable VPLL_INT pll. Because of 1), the function zynqmp_pll_enable just returns without doing anything after checking that this pll has been enabled. In the scenario above, the pll mode of VPLL_INT will never be set successfully. So adding set_pll_mode to check condition to fix it. Fixes: 3fde0e16 ("drivers: clk: Add ZynqMP clock driver") Signed-off-by:
Quanyang Wang <quanyang.wang@windriver.com> Tested-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Link: https://lore.kernel.org/r/20210406153131.601701-1-quanyang.wang@windriver.com Signed-off-by:
-
Quanyang Wang authored
[ Upstream commit d7fd3f9f ] The round_rate callback should only perform rate calculation and not involve calling zynqmp_pll_set_mode to change the pll mode. So let's move zynqmp_pll_set_mode out of round_rate and to set_rate callback. Fixes: 3fde0e16 ("drivers: clk: Add ZynqMP clock driver") Reported-by:
-
Jason Gunthorpe authored
[ Upstream commit b5a1f892 ] There is a small race where the parent is NULL even though the kobj has already been made visible in sysfs. For instance the attribute_group is made visible in sysfs_create_files() and the mdev_type_attr_show() does: ret = attr->show(kobj, type->parent->dev, buf); Which will crash on NULL parent. Move the parent setup to before the type pointer leaves the stack frame. Fixes: 7b96953b ("vfio: Mediated device Core driver") Reviewed-by:
Kevin Tian <kevin.tian@intel.com> Reviewed-by:
Max Gurtovoy <mgurtovoy@nvidia.com> Reviewed-by:
Cornelia Huck <cohuck@redhat.com> Signed-off-by:
Jason Gunthorpe <jgg@nvidia.com> Message-Id: <2-v2-d36939638fc6+d54-vfio2_jgg@nvidia.com> Signed-off-by:
Alex Williamson <alex.williamson@redhat.com> Signed-off-by:
-
Jason Gunthorpe authored
[ Upstream commit 4aeec398 ] vfio_add_group_dev() must be called only after all of the private data in vdev is fully setup and ready, otherwise there could be races with user space instantiating a device file descriptor and starting to call ops. For instance vfio_pci_reflck_attach() sets vdev->reflck and vfio_pci_open(), called by fops open, unconditionally derefs it, which will crash if things get out of order. Fixes: cc20d799 ("vfio/pci: Introduce VF token") Fixes: e309df5b ("vfio/pci: Parallelize device open and release") Fixes: 6eb70187 ("vfio-pci: Move idle devices to D3hot power state") Fixes: ecaa1f6a ("vfio-pci: Add VGA arbiter client") Reviewed-by:
Eric Auger <eric.auger@redhat.com> Signed-off-by:
-
Jason Gunthorpe authored
[ Upstream commit 61e90817 ] vfio_pci_probe() is quite complicated, with optional VF and VGA sub components. Move these into clear init/uninit functions and have a linear flow in probe/remove. This fixes a few little buglets: - vfio_pci_remove() is in the wrong order, vga_client_register() removes a notifier and is after kfree(vdev), but the notifier refers to vdev, so it can use after free in a race. - vga_client_register() can fail but was ignored Organize things so destruction order is the reverse of creation order. Fixes: ecaa1f6a ("vfio-pci: Add VGA arbiter client") Reviewed-by:
-
Jason Gunthorpe authored
[ Upstream commit 2b1fe162 ] vfio_add_group_dev() must be called only after all of the private data in vdev is fully setup and ready, otherwise there could be races with user space instantiating a device file descriptor and starting to call ops. For instance vfio_fsl_mc_reflck_attach() sets vdev->reflck and vfio_fsl_mc_open(), called by fops open, unconditionally derefs it, which will crash if things get out of order. This driver started life with the right sequence, but two commits added stuff after vfio_add_group_dev(). Fixes: 2e0d2956 ("vfio/fsl-mc: Add irq infrastructure for fsl-mc devices") Fixes: f2ba7e8c ("vfio/fsl-mc: Added lock support in preparation for interrupt handling") Co-developed-by:
Diana Craciun OSS <diana.craciun@oss.nxp.com> Signed-off-by:
-
Hans Verkuil authored
[ Upstream commit be7e8af9 ] When a request is re-inited it will release all control handler objects that are still in the request. It does that by unbinding and putting all those objects. When the object is unbound the obj->req pointer is set to NULL, and the object's unbind op is called. When the object it put the object's release op is called to free the memory. For a request object that contains a control handler that means that v4l2_ctrl_handler_free() is called in the release op. A control handler used in a request has a pointer to the main control handler that is created by the driver and contains the current state of all controls. If the device is unbound (due to rmmod or a forced unbind), then that main handler is freed, again by calling v4l2_ctrl_handler_free(), and any outstanding request objects that refer to that main handler have to be unbound and put as well. It does that by this test: if (!hdl->req_obj.req && !list_empty(&hdl->requests)) { I.e. the handler has no pointer to a request, so is the main handler, and one or more request objects refer to this main handler. However, this test is wrong since hdl->req_obj.req is actually NULL when re-initing a request (the object unbind will set req to NULL), and the only reason this seemingly worked is that the requests list is typically empty since the request's unbind op will remove the handler from the requests list. But if another thread is at the same time adding a new control to a request, then there is a race condition where one thread is removing a control handler object from the requests list and another thread is adding one. The result is that hdl->requests is no longer empty and the code thinks that a main handler is being freed instead of a control handler that is part of a request. There are two bugs here: first the test for hdl->req_obj.req: this should be hdl->req_obj.ops since only the main control handler will have a NULL pointer there. The second is that adding or deleting request objects from the requests list of the main handler isn't protected by taking the main handler's lock. Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Reported-by:
John Cox <jc@kynesim.co.uk> Fixes: 6fa6f831 ("media: v4l2-ctrls: add core request support") Tested-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Signed-off-by:
-
Lad Prabhakar authored
[ Upstream commit dd90caa0 ] Move incrementing/decrementing runtime PM count to imx219_start_streaming()/imx219_stop_streaming() functions respectively. This fixes an issue of unbalanced runtime PM count in resume callback error path where streaming is stopped and runtime PM count is left unbalanced. Fixes: 1283b3b8 ("media: i2c: Add driver for Sony IMX219 sensor") Reported-by:
Pavel Machek <pavel@denx.de> Signed-off-by:
Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by:
Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by:
-
Lad Prabhakar authored
[ Upstream commit 745d4612 ] Move out locking/unlocking of vflip and hflip controls from imx219_set_stream() to the imx219_start_streaming()/ imx219_stop_streaming() respectively. This fixes an issue in resume callback error path where streaming is stopped and the controls are left in locked state. Fixes: 1283b3b8 ("media: i2c: Add driver for Sony IMX219 sensor") Reported-by:
-
Hannes Reinecke authored
[ Upstream commit dd8f7fa9 ] If ANA is enabled but no ANA group descriptor is found when creating a new namespace the ANA log is most likely out of date, so trigger a re-read. The namespace will be tagged with the NS_ANA_PENDING flag to exclude it from path selection until the ANA log has been re-read. Fixes: 32acab31 ("nvme: implement multipath access to nvme subsystems") Reported-by:
Martin George <marting@netapp.com> Signed-off-by:
Hannes Reinecke <hare@suse.de> Reviewed-by:
Keith Busch <kbusch@kernel.org> Reviewed-by:
-
Ricardo Rivera-Matos authored
[ Upstream commit 04722cec ] Currently POWER_SUPPLY_PROP_CONSTANT_CHARGE_CURRENT and POWER_SUPPLY_PROP_CONSTANT_CHARGE_VOLTAGE are exposed on the battery node and this is incorrect. This patch exposes both of them on the charger node rather than the battery node. Fixes: 5069185f ("power: supply: bq25980: Add support for the BQ259xx family") Signed-off-by:
Ricardo Rivera-Matos <r-rivera-matos@ti.com> Signed-off-by:
Sebastian Reichel <sebastian.reichel@collabora.com> Signed-off-by:
-
Adam Ford authored
[ Upstream commit 379c9a24 ] Most if not all i.MX SoC's call a function which enables all UARTS. This is a problem for users who need to re-parent the clock source, because any attempt to change the parent results in an busy error due to the fact that the clocks have been enabled already. clk: failed to reparent uart1 to sys_pll1_80m: -16 Instead of pre-initializing all UARTS, scan the device tree to see which UART clocks are associated to stdout, and only enable those UART clocks if it's needed early. This will move initialization of the remaining clocks until after the parenting of the clocks. When the clocks are shutdown, this mechanism will also disable any clocks that were pre-initialized. Fixes: 9461f7b3 ("clk: fix CLK_SET_RATE_GATE with clock rate protection") Suggested-by:
Aisheng Dong <aisheng.dong@nxp.com> Signed-off-by:
Adam Ford <aford173@gmail.com> Reviewed-by:
Abel Vesa <abel.vesa@nxp.com> Tested-by:
Ahmad Fatoum <a.fatoum@pengutronix.de> Signed-off-by:
-
Sagi Grimberg authored
[ Upstream commit b5332a9f ] We are not changing anything in the TCP connection state so we should not take a write_lock but rather a read lock. This caused a deadlock when running nvmet-tcp and nvme-tcp on the same system, where state_change callbacks on the host and on the controller side have causal relationship and made lockdep report on this with blktests: ================================ WARNING: inconsistent lock state 5.12.0-rc3 #1 Tainted: G I -------------------------------- inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-R} usage. nvme/1324 [HC0[0]:SC0[0]:HE1:SE1] takes: ffff888363151000 (clock-AF_INET){++-?}-{2:2}, at: nvme_tcp_state_change+0x21/0x150 [nvme_tcp] {IN-SOFTIRQ-W} state was registered at: __lock_acquire+0x79b/0x18d0 lock_acquire+0x1ca/0x480 _raw_write_lock_bh+0x39/0x80 nvmet_tcp_state_change+0x21/0x170 [nvmet_tcp] tcp_fin+0x2a8/0x780 tcp_data_queue+0xf94/0x1f20 tcp_rcv_established+0x6ba/0x1f00 tcp_v4_do_rcv+0x502/0x760 tcp_v4_rcv+0x257e/0x3430 ip_protocol_deliver_rcu+0x69/0x6a0 ip_local_deliver_finish+0x1e2/0x2f0 ip_local_deliver+0x1a2/0x420 ip_rcv+0x4fb/0x6b0 __netif_receive_skb_one_core+0x162/0x1b0 process_backlog+0x1ff/0x770 __napi_poll.constprop.0+0xa9/0x5c0 net_rx_action+0x7b3/0xb30 __do_softirq+0x1f0/0x940 do_softirq+0xa1/0xd0 __local_bh_enable_ip+0xd8/0x100 ip_finish_output2+0x6b7/0x18a0 __ip_queue_xmit+0x706/0x1aa0 __tcp_transmit_skb+0x2068/0x2e20 tcp_write_xmit+0xc9e/0x2bb0 __tcp_push_pending_frames+0x92/0x310 inet_shutdown+0x158/0x300 __nvme_tcp_stop_queue+0x36/0x270 [nvme_tcp] nvme_tcp_stop_queue+0x87/0xb0 [nvme_tcp] nvme_tcp_teardown_admin_queue+0x69/0xe0 [nvme_tcp] nvme_do_delete_ctrl+0x100/0x10c [nvme_core] nvme_sysfs_delete.cold+0x8/0xd [nvme_core] kernfs_fop_write_iter+0x2c7/0x460 new_sync_write+0x36c/0x610 vfs_write+0x5c0/0x870 ksys_write+0xf9/0x1d0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae irq event stamp: 10687 hardirqs last enabled at (10687): [<ffffffff9ec376bd>] _raw_spin_unlock_irqrestore+0x2d/0x40 hardirqs last disabled at (10686): [<ffffffff9ec374d8>] _raw_spin_lock_irqsave+0x68/0x90 softirqs last enabled at (10684): [<ffffffff9f000608>] __do_softirq+0x608/0x940 softirqs last disabled at (10649): [<ffffffff9cdedd31>] do_softirq+0xa1/0xd0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(clock-AF_INET); <Interrupt> lock(clock-AF_INET); *** DEADLOCK *** 5 locks held by nvme/1324: #0: ffff8884a01fe470 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xf9/0x1d0 #1: ffff8886e435c090 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x216/0x460 #2: ffff888104d90c38 (kn->active#255){++++}-{0:0}, at: kernfs_remove_self+0x22d/0x330 #3: ffff8884634538d0 (&queue->queue_lock){+.+.}-{3:3}, at: nvme_tcp_stop_queue+0x52/0xb0 [nvme_tcp] #4: ffff888363150d30 (sk_lock-AF_INET){+.+.}-{0:0}, at: inet_shutdown+0x59/0x300 stack backtrace: CPU: 26 PID: 1324 Comm: nvme Tainted: G I 5.12.0-rc3 #1 Hardware name: Dell Inc. PowerEdge R640/06NR82, BIOS 2.10.0 11/12/2020 Call Trace: dump_stack+0x93/0xc2 mark_lock_irq.cold+0x2c/0xb3 ? verify_lock_unused+0x390/0x390 ? stack_trace_consume_entry+0x160/0x160 ? lock_downgrade+0x100/0x100 ? save_trace+0x88/0x5e0 ? _raw_spin_unlock_irqrestore+0x2d/0x40 mark_lock+0x530/0x1470 ? mark_lock_irq+0x1d10/0x1d10 ? enqueue_timer+0x660/0x660 mark_usage+0x215/0x2a0 __lock_acquire+0x79b/0x18d0 ? tcp_schedule_loss_probe.part.0+0x38c/0x520 lock_acquire+0x1ca/0x480 ? nvme_tcp_state_change+0x21/0x150 [nvme_tcp] ? rcu_read_unlock+0x40/0x40 ? tcp_mtu_probe+0x1ae0/0x1ae0 ? kmalloc_reserve+0xa0/0xa0 ? sysfs_file_ops+0x170/0x170 _raw_read_lock+0x3d/0xa0 ? nvme_tcp_state_change+0x21/0x150 [nvme_tcp] nvme_tcp_state_change+0x21/0x150 [nvme_tcp] ? sysfs_file_ops+0x170/0x170 inet_shutdown+0x189/0x300 __nvme_tcp_stop_queue+0x36/0x270 [nvme_tcp] nvme_tcp_stop_queue+0x87/0xb0 [nvme_tcp] nvme_tcp_teardown_admin_queue+0x69/0xe0 [nvme_tcp] nvme_do_delete_ctrl+0x100/0x10c [nvme_core] nvme_sysfs_delete.cold+0x8/0xd [nvme_core] kernfs_fop_write_iter+0x2c7/0x460 new_sync_write+0x36c/0x610 ? new_sync_read+0x600/0x600 ? lock_acquire+0x1ca/0x480 ? rcu_read_unlock+0x40/0x40 ? lock_is_held_type+0x9a/0x110 vfs_write+0x5c0/0x870 ksys_write+0xf9/0x1d0 ? __ia32_sys_read+0xa0/0xa0 ? lockdep_hardirqs_on_prepare.part.0+0x198/0x340 ? syscall_enter_from_user_mode+0x27/0x70 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae Fixes: 872d26a3 ("nvmet-tcp: add NVMe over TCP target driver") Reported-by:
Yi Zhang <yi.zhang@redhat.com> Signed-off-by:
-
Sagi Grimberg authored
[ Upstream commit 8b73b45d ] The TCP stack can run from process context for a long time so we should disable BH here. Fixes: 3f2304f8 ("nvme-tcp: add NVMe over TCP host driver") Signed-off-by:
-
Kenta.Tada@sony.com authored
[ Upstream commit 64bdc024 ] Strictly speaking, seccomp filters are only used when CONFIG_SECCOMP_FILTER. This patch fixes the condition to enable "Seccomp_filters" in /proc/$pid/status. Signed-off-by:
Kenta Tada <Kenta.Tada@sony.com> Fixes: c818c03b ("seccomp: Report number of loaded filters in /proc/$pid/status") Signed-off-by:
Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/OSBPR01MB26772D245E2CF4F26B76A989F5669@OSBPR01MB2677.jpnprd01.prod.outlook.com Signed-off-by:
-
Sergey Shtylyov authored
[ Upstream commit b30d0040 ] Iff platform_get_irq() returns 0, ahci_platform_init_host() would return 0 early (as if the call was successful). Override IRQ0 with -EINVAL instead as the 'libata' regards 0 as "no IRQ" (thus polling) anyway... Fixes: c034640a ("ata: libahci: properly propagate return value of platform_get_irq()") Signed-off-by:
Jens Axboe <axboe@kernel.dk> Signed-off-by:
-
Sergey Shtylyov authored
[ Upstream commit e6471a65 ] The function mv_platform_probe() neglects to check the results of the calls to platform_get_irq() and irq_of_parse_and_map() and blithely passes them to ata_host_activate() -- while the latter only checks for IRQ0 (treating it as a polling mode indicattion) and passes the negative values to devm_request_irq() causing it to fail as it takes unsigned values for the IRQ #... Add to mv_platform_probe() the proper IRQ checks to pass the positive IRQ #s to ata_host_activate(), propagate upstream the negative error codes, and override the IRQ0 with -EINVAL (as we don't want the polling mode). Fixes: f351b2d6 ("sata_mv: Support SoC controllers") Signed-off-by:
-
Sergey Shtylyov authored
[ Upstream commit e379b40c ] The driver's probe() method is written as if platform_get_irq() returns 0 on error, while actually it returns a negative error code (with all the other values considered valid IRQs). Rewrite the driver's IRQ checking code to pass the positive IRQ #s to ata_host_activate(), propagate errors upstream, and treat IRQ0 as error, returning -EINVAL, as the libata code treats 0 as an indication that polling should be used anyway... Fixes: 0df0d0a0 ("[libata] ARM: add ixp4xx PATA driver") Signed-off-by:
-
Sergey Shtylyov authored
[ Upstream commit c7e8f404 ] The driver's probe() method is written as if platform_get_irq() returns 0 on error, while actually it returns a negative error code (with all the other values considered valid IRQs). Rewrite the driver's IRQ checking code to pass the positive IRQ #s to ata_host_activate(), propagate upstream -EPROBE_DEFER, and set up the driver to polling mode on (negative) errors and IRQ0 (libata treats IRQ #0 as a polling mode anyway)... Fixes: a480167b ("pata_arasan_cf: Adding support for arasan compact flash host controller") Signed-off-by:
Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by:
-
Ilya Leoshkevich authored
[ Upstream commit cb4969e6 ] Currently the following command produces an error message: linux# make kselftest TARGETS=bpf O=/mnt/linux-build # selftests: bpf: test_libbpf.sh # ./test_libbpf.sh: line 23: ./test_libbpf_open: No such file or directory # test_libbpf: failed at file test_l4lb.o # selftests: test_libbpf [FAILED] The error message might not affect the return code of make, therefore one needs to grep make output in order to detect it. This is not the only instance of the same underlying problem; any test with more than one element in $(TEST_PROGS) fails the same way. Another example: linux# make O=/mnt/linux-build TARGETS=splice kselftest [...] # ./short_splice_read.sh: 15: ./splice_read: not found # FAIL: /sys/module/test_module/sections/.init.text 2 not ok 2 selftests: splice: short_splice_read.sh # exit=1 The current logic prepends $(OUTPUT) only to the first member of $(TEST_PROGS). After that, run_one() does cd `dirname $TEST` For all tests except the first one, `dirname $TEST` is ., which means they cannot access the files generated in $(OUTPUT). Fix by using $(addprefix) to prepend $(OUTPUT)/ to each member of $(TEST_PROGS). Fixes: 1a940687 ("selftests: lib.mk: copy test scripts and test files for make O=dir run") Signed-off-by:
Ilya Leoshkevich <iii@linux.ibm.com> Signed-off-by:
Shuah Khan <skhan@linuxfoundation.org> Signed-off-by:
-
Masami Hiramatsu authored
[ Upstream commit 6dd3b8c9 ] There are 2 bugs in the can_boost() function because of using x86 insn decoder. Since the insn->opcode never has a prefix byte, it can not find CS override prefix in it. And the insn->attr is the attribute of the opcode, thus inat_is_address_size_prefix( insn->attr) always returns false. Fix those by checking each prefix bytes with for_each_insn_prefix loop and getting the correct attribute for each prefix byte. Also, this removes unlikely, because this is a slow path. Fixes: a8d11cd0 ("kprobes/x86: Consolidate insn decoder users for copying code") Signed-off-by:
Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by:
Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/161666691162.1120877.2808435205294352583.stgit@devnote2 Signed-off-by:
-
kernel test robot authored
[ Upstream commit c4d74f0f ] Function "for_each_child_of_node" should have of_node_put() before goto. Generated by: scripts/coccinelle/iterators/for_each_child.cocci Fixes: 82c2d813 ("coccinelle: iterators: Add for_each_child.cocci script") CC: Sumera Priyadarsini <sylphrenadin@gmail.com> Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
Julia Lawall <julia.lawall@inria.fr> Reviewed-by:
Frank Rowand <frank.rowand@sony.com> Tested-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
Felix Kuehling authored
[ Upstream commit 1e870685 ] Using 'imply AMD_IOMMU_V2' does not guarantee that the driver can link against the exported functions. If the GPU driver is built-in but the IOMMU driver is a loadable module, the kfd_iommu.c file is indeed built but does not work: x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function `kfd_iommu_bind_process_to_device': kfd_iommu.c:(.text+0x516): undefined reference to `amd_iommu_bind_pasid' x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function `kfd_iommu_unbind_process': kfd_iommu.c:(.text+0x691): undefined reference to `amd_iommu_unbind_pasid' x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function `kfd_iommu_suspend': kfd_iommu.c:(.text+0x966): undefined reference to `amd_iommu_set_invalidate_ctx_cb' x86_64-linux-ld: kfd_iommu.c:(.text+0x97f): undefined reference to `amd_iommu_set_invalid_ppr_cb' x86_64-linux-ld: kfd_iommu.c:(.text+0x9a4): undefined reference to `amd_iommu_free_device' x86_64-linux-ld: drivers/gpu/drm/amd/amdkfd/kfd_iommu.o: in function `kfd_iommu_resume': kfd_iommu.c:(.text+0xa9a): undefined reference to `amd_iommu_init_device' x86_64-linux-ld: kfd_iommu.c:(.text+0xadc): undefined reference to `amd_iommu_set_invalidate_ctx_cb' x86_64-linux-ld: kfd_iommu.c:(.text+0xaff): undefined reference to `amd_iommu_set_invalid_ppr_cb' x86_64-linux-ld: kfd_iommu.c:(.text+0xc72): undefined reference to `amd_iommu_bind_pasid' x86_64-linux-ld: kfd_iommu.c:(.text+0xe08): undefined reference to `amd_iommu_set_invalidate_ctx_cb' x86_64-linux-ld: kfd_iommu.c:(.text+0xe26): undefined reference to `amd_iommu_set_invalid_ppr_cb' x86_64-linux-ld: kfd_iommu.c:(.text+0xe42): undefined reference to `amd_iommu_free_device' Use IS_REACHABLE to only build IOMMU-V2 support if the amd_iommu symbols are reachable by the amdkfd driver. Output a warning if they are not, because that may not be what the user was expecting. Fixes: 64d1c3a4 ("drm/amdkfd: Centralize IOMMUv2 code and make it conditional") Reported-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
