blk_mq_tag_to_rq() will always return a request if the command_id is
in the valid range. Check if the request has been started. If we
blindly process the request we might double complete a request which
can be fatal.
How did you get to this one? did the controller send a completion
r8a779a0 (V3U) support
* removal of sirf prima watchdog driver
* removal of sirf atlas watchdog driver
* removal of zte zx watchdog driver
* removal of tango watchdog driver
* removal of coh901 watchdog driver
* several fixes and clean-ups
The output from git request-pull
ave interrupts which are enabled
i2c: iproc: update slave isr mask (ISR_MASK_SLAVE)
i2c: iproc: fix typo in slave_isr function
i2c: iproc: handle master read request
i2c: iproc: handle rx fifo full interrupt
Richard Neumann (2):
i2c: amd-mp2: convert to PCI logging functi
On Sat, Feb 13, 2021 at 09:46:41AM +0100, Hannes Reinecke wrote:
> On 2/12/21 10:49 PM, Sagi Grimberg wrote:
> >
> > > > > blk_mq_tag_to_rq() will always return a request if the command_id is
> > > > > in the valid range. Check if the request has been s
The pull request you sent on Sat, 13 Feb 2021 11:42:00 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-current
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8cc8e6aaf27db47985f9e1c24ac2f7393390971e
Thank you!
--
Deet-doot-dot, I
Linus,
here is one more I2C driver bugfix. Please pull.
Thanks,
Wolfram
The following changes since commit 92bf22614b21a2706f4993b278017e437f7785b3:
Linux 5.11-rc7 (2021-02-07 13:57:38 -0800)
are available in the Git repository at:
On 2/12/21 10:49 PM, Sagi Grimberg wrote:
blk_mq_tag_to_rq() will always return a request if the command_id is
in the valid range. Check if the request has been started. If we
blindly process the request we might double complete a request which
can be fatal.
How did you get to this one? did
On 2/12/21 7:17 PM, Daniel Wagner wrote:
blk_mq_tag_to_rq() will always return a request if the command_id is
in the valid range. Check if the request has been started. If we
blindly process the request we might double complete a request which
can be fatal.
Signed-off-by: Daniel Wagner
blk_mq_tag_to_rq() will always return a request if the command_id is
in the valid range. Check if the request has been started. If we
blindly process the request we might double complete a request which
can be fatal.
How did you get to this one? did the controller send a completion
On Fri, Feb 12, 2021 at 12:58:27PM -0800, Sagi Grimberg wrote:
> > blk_mq_tag_to_rq() will always return a request if the command_id is
> > in the valid range. Check if the request has been started. If we
> > blindly process the request we might double complete a request whic
blk_mq_tag_to_rq() will always return a request if the command_id is
in the valid range. Check if the request has been started. If we
blindly process the request we might double complete a request which
can be fatal.
How did you get to this one? did the controller send a completion
blk_mq_tag_to_rq() will always return a request if the command_id is
in the valid range. Check if the request has been started. If we
blindly process the request we might double complete a request which
can be fatal.
Signed-off-by: Daniel Wagner
---
This patch is against nvme-5.12
This patch introduces the capability to detach a remote processor
that has been attached to or booted by the remoteproc core. For
that to happen a rproc::ops::detach() operation need to be
available.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
This patch takes into account scenarios where a remote processor
has been attached to when receiving a "start" command from sysfs.
As with the "running" case, the command can't be carried out if the
remote processor is already in operation.
Signed-off-by: Mathieu Poirier
Reviewed-by: Arnaud
This patch introduces the capability to stop a remote processor
that has been attached to by the remoteproc core. For that to
happen a rproc::ops::stop() operation need to be available.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
From: Michal Rostecki
Add a per-CPU inflight BIO counter to btrfs_device which stores the
number of requests currently processed by the device. This information
is going to be used in roundrobin raid1 read policy.
Signed-off-by: Michal Rostecki
---
fs/btrfs/volumes.c | 11 +--
Nuno Das Neves writes:
> Reserve ioctl number in userpsace-api/ioctl/ioctl-number.rst
> Introduce MSHV_REQUEST_VERSION ioctl.
> Introduce documentation for /dev/mshv in Documentation/virt/mshv
>
> Signed-off-by: Nuno Das Neves
> ---
> .../userspace-api/ioctl/ioctl-number.rst | 2 +
>
On Mon, Feb 08, 2021 at 06:30:22PM +0200, Oded Gabbay wrote:
> Hi Greg,
>
> This is habanalabs second pull request for the merge window of
> kernel 5.12.
> It contains important fixes, especially in the firmware-related code.
> Details are in the tag.
>
> Thanks,
&
From: Nuno Das Neves Sent: Friday, November
20, 2020 4:30 PM
>
> Reserve ioctl number in userpsace-api/ioctl/ioctl-number.rst
> Introduce MSHV_REQUEST_VERSION ioctl.
> Introduce documentation for /dev/mshv in Documentation/virt/mshv
>
> Signed-off-by: Nuno Das Neves
> ---
>
Hi Greg,
This is habanalabs second pull request for the merge window of
kernel 5.12.
It contains important fixes, especially in the firmware-related code.
Details are in the tag.
Thanks,
Oded
The following changes since commit 369aea84595189200a2e6b028f556a7efa0ec489:
mei: implement client
From: Pavel Shilovsky
commit 91792bb8089b63b7b780251eb83939348ac58a64 upstream.
Currently we try to guess if a compound request is going to
succeed waiting for credits or not based on the number of
requests in flight. This approach doesn't work correctly
all the time because there may be only
From: Pavel Shilovsky
commit 91792bb8089b63b7b780251eb83939348ac58a64 upstream.
Currently we try to guess if a compound request is going to
succeed waiting for credits or not based on the number of
requests in flight. This approach doesn't work correctly
all the time because there may be only
eed_down before */
phylink_speed_up(priv->phylink);
- /* Request the IRQ lines */
- ret = request_irq(dev->irq, stmmac_interrupt,
- IRQF_SHARED, dev->name, dev);
- if (unlikely(ret < 0)) {
- netdev_err(priv->dev,
-
Since the Tx/Rx clocks with the same names are now requested and
enabled/disabled in the STMMAC DT-based platform config method, there is
no need in duplicating the same procedures in the DWC QoS Eth sub-driver.
Discard it then, but make sure the denoted clocks have been specified
for the
Since the Tx clock is now requested and enabled/disabled in the STMMAC
DT-based platform config method, there is no need in duplicating the same
procedures in the DW MAC iMX sub-driver.
Signed-off-by: Serge Semin
---
.../net/ethernet/stmicro/stmmac/dwmac-imx.c | 21 +--
1 file
will come out if the PTP clock has been actually
specified, but the clock framework failed to request it.
Note since we are switching the code to using the optional common clock
API, then there is no need in checking the clk_ptp_ref pointer for being
not NULL before calling the clk_prepare_enable() method
procedure
will just proceed with further initializations. It is erroneous in both
cases. Secondly if we'd use the clock API, which expect the clock being
optional we wouldn't have needed to avoid the clock request procedure for
the "snps,dwc-qos-ethernet-4.10"-compatible devices to prevent th
From: Shuo Liu
An I/O request of a User VM, which is constructed by the hypervisor, is
distributed by the ACRN Hypervisor Service Module to an I/O client
corresponding to the address range of the I/O request.
For each User VM, there is a shared 4-KByte memory region used for I/O
requests
On 2/4/21 10:09 PM, Can Guo wrote:
> That code is wrong. The Task Tag in Dword_0 should be the real tag we
> allocated for TMR. The transfer request Task Tag which we are trying to
> abort is given in Dword_5, which is the Input Parameter 3 of the TMR UPIU.
> I am not sure why the aut
On Fri, Feb 05, 2021 at 03:24:06PM +0100, Ulf Hansson wrote:
> On Thu, 21 Jan 2021 at 09:13, Liu Xiang wrote:
> >
> > After commit "40d09b53bfc557af7481b9d80f060a7ac9c7d314", request is
> > completed in softirq. This may cause the system to suffer bad preemptoff
&
From: Chao Leng
[ Upstream commit 9ebbfe495ecd2e51bc92ac21ed5817c3b9e223ce ]
Each name space has a request queue, if complete request long time,
multi request queues may have time out requests at the same time,
nvme_tcp_timeout will execute concurrently. Multi requests in different
request
+ Adrian, Christoph
On Thu, 21 Jan 2021 at 09:13, Liu Xiang wrote:
>
> After commit "40d09b53bfc557af7481b9d80f060a7ac9c7d314", request is
> completed in softirq. This may cause the system to suffer bad preemptoff
> time.
> The mmc driver has its own complete workq
From: Chao Leng
[ Upstream commit 7674073b2ed35ac951a49c425dec6b39d5a57140 ]
A crash happens when inject completing request long time(nearly 30s).
Each name space has a request queue, when inject completing request long
time, multi request queues may have time out requests at the same time
ags) == QP_STOP))
+ return;
+
if (qp->event_cb) {
qp->event_cb(qp);
return;
@@ -1868,6 +1871,28 @@ int hisi_qm_start_qp(struct hisi_qp *qp, unsigned long
arg)
EXPORT_SYMBOL_GPL(hisi_qm_start_qp);
/**
+ * qp_stop_fail_cb() - call request cb
port?
That code is wrong. The Task Tag in Dword_0 should be the real tag we
allocated for TMR. The transfer request Task Tag which we are trying to
abort is given in Dword_5, which is the Input Parameter 3 of the TMR
UPIU.
I am not sure why the author gave hba->nutrs + req->tag as the Task
On Wed, Jan 27, 2021 at 09:29:22PM +0200, Oded Gabbay wrote:
> Hi Greg,
>
> This is habanalabs pull request for the merge window of kernel 5.12.
> It contains changes and new features, support for new firmware.
> Details are in the tag.
>
> Thanks,
> Oded
>
> The
Replace r8153_patch_request() with rtl_phy_patch_request().
Replace r8153_pre_ram_code() with rtl_pre_ram_code().
Replace r8153_post_ram_code() with rtl_post_ram_code().
Add rtl_patch_key_set().
The new functions have an additional parameter. It is used to wait
the patch request command finished
On 1/28/21 9:57 PM, Can Guo wrote:
> On 2021-01-29 11:15, Bart Van Assche wrote:
>> On 1/27/21 8:16 PM, Can Guo wrote:
>>> In __ufshcd_issue_tm_cmd(), it is not right to use hba->nutrs +
>>> req->tag as
>>> the Task Tag in one TMR UPIU. Directly use req->tag as the Task Tag.
>>
>> Why is the
On 1/28/21 10:29 PM, Can Guo wrote:
> On second thought, actually the 1st fix alone is enough to eliminate the
> race condition. Because blk_mq_tagset_busy_iter() only iterates over all
> requests which are not in IDLE state, if blk_mq_start_request() is called
> within the protection of host spin
On Sun, Jan 31, 2021 at 3:40 AM Wolfram Sang wrote:
>
> one I2C driver update this time.
Pulled (manual notification because the automation seems very flaky).
Linus
Linus,
one I2C driver update this time.
Please pull.
Thanks,
Wolfram
The following changes since commit 6ee1d745b7c9fd573fba142a2efdad76a9f1cb04:
Linux 5.11-rc5 (2021-01-24 16:47:14 -0800)
are available in the Git repository at:
From: Govind Singh
Use request exclusive reset control for wcss reset controls.
Signed-off-by: Govind Singh
Signed-off-by: Gokul Sriram Palanisamy
---
drivers/remoteproc/qcom_q6v5_wcss.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/remoteproc
k layer core to
handle
races between request completion and timeout handling.
This patch is not introducing any new mechanism, it is fixing the
usage of completion (req->end_io_data = c) introduced by commit
69a6c269c097 ("scsi: ufs: Use blk_{get,put}_request() to allocate
and free TMFs&q
aces
between submission and completion context. Can the block layer timeout
mechanism be used instead of the mechanism introduced by this patch,
e.g. by using blk_execute_rq_nowait() to submit requests? That would
allow to reuse the existing mechanism in the block layer core to handle
races bet
On 2021-01-29 11:15, Bart Van Assche wrote:
On 1/27/21 8:16 PM, Can Guo wrote:
In __ufshcd_issue_tm_cmd(), it is not right to use hba->nutrs +
req->tag as
the Task Tag in one TMR UPIU. Directly use req->tag as the Task Tag.
Why is the current code wrong and why is this patch the proper fix?
ck_irqsave(host->host_lock, flags);
task_tag = hba->nutrs + free_slot;
+ blk_mq_start_request(req);
treq->req_header.dword_0 |= cpu_to_be32(task_tag);
blk_mq_start_request() not only marks a request as in-flight but also
starts a timer. However, no timeout handl
(struct ufs_hba *hba,
>
> spin_lock_irqsave(host->host_lock, flags);
> task_tag = hba->nutrs + free_slot;
> + blk_mq_start_request(req);
>
> treq->req_header.dword_0 |= cpu_to_be32(task_tag);
blk_mq_start_request() not only marks a request as in-
een submission and completion context. Can the block layer timeout
mechanism be used instead of the mechanism introduced by this patch,
e.g. by using blk_execute_rq_nowait() to submit requests? That would
allow to reuse the existing mechanism in the block layer core to handle
races between reques
On 1/27/21 8:16 PM, Can Guo wrote:
> In __ufshcd_issue_tm_cmd(), it is not right to use hba->nutrs + req->tag as
> the Task Tag in one TMR UPIU. Directly use req->tag as the Task Tag.
Why is the current code wrong and why is this patch the proper fix?
Please explain this in the patch description.
From: Govind Singh
Use request exclusive reset control for wcss reset controls.
Signed-off-by: Govind Singh
Signed-off-by: Gokul Sriram Palanisamy
---
drivers/remoteproc/qcom_q6v5_wcss.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/remoteproc
84,33 @@ static int __ufshcd_issue_tm_cmd(struct ufs_hba *hba,
DECLARE_COMPLETION_ONSTACK(wait);
struct request *req;
unsigned long flags;
- int free_slot, task_tag, err;
+ int task_tag, err;
/*
-* Get free slot, sleep if slots are unavailable.
-* Even thoug
_errors(struct ufs_hba
*hba)
struct ctm_info {
struct ufs_hba *hba;
- unsigned long pending;
+ unsigned long completed;
unsigned intncpl;
};
@@ -6234,13 +6234,13 @@ static bool ufshcd_compl_tm(struct request *req, void
*priv, bool reserved)
str
ufshcd_tmc_handler() calls blk_mq_tagset_busy_iter(fn = ufshcd_compl_tm()),
but since blk_mq_tagset_busy_iter() only iterates over all reserved tags
and requests which are not in IDLE state, ufshcd_compl_tm() never gets a
chance to run. Thus, TMR always ends up with completion timeout. Fix it by
Hi Greg,
This is habanalabs pull request for the merge window of kernel 5.12.
It contains changes and new features, support for new firmware.
Details are in the tag.
Thanks,
Oded
The following changes since commit 0fc99422bc034de018607ef6b70f92d4bc4a236d:
firmware: xilinx: Remove PM_API_MAX
Eric W. Biederman writes:
> [Please note this e-mail is from an EXTERNAL e-mail address]
>
> Yahu Gao writes:
>
>> There is a kernel NULL pointer dereference was found in Linux system.
>> The details of kernel NULL is shown at bellow.
>>
>> Currently, we do not have a way to provoke this
Eric W. Biederman writes:
> [Please note this e-mail is from an EXTERNAL e-mail address]
>
> Yahu Gao writes:
>
>> There is a kernel NULL pointer dereference was found in Linux system.
>> The details of kernel NULL is shown at bellow.
>>
>> Currently, we do not have a way to provoke this
On 1/20/21 7:23 PM, Can Guo wrote:
> Current task management request send/compl implementation is broken, the
> problems and fixes are listed as below:
>
> Problem: TMR completion timeout. ufshcd_tmc_handler() calls
> blk_mq_tagset_busy_iter(fn == ufshcd_compl_t
> Current task management request send/compl implementation is broken, the
> problems and fixes are listed as below:
>
> Problem: TMR completion timeout. ufshcd_tmc_handler() calls
> blk_mq_tagset_busy_iter(fn == ufshcd_compl_tm()), but since
> blk_mq_tagse
On 2021-01-25 19:36, Avri Altman wrote:
Current task management request send/compl implementation is broken,
the
problems and fixes are listed as below:
Problem: TMR completion timeout. ufshcd_tmc_handler() calls
blk_mq_tagset_busy_iter(fn == ufshcd_compl_tm()), but since
From: Jaegeuk Kim
[ Upstream commit eeb1b55b6e25c5f7265ff45cd050f3bc2cc423a4 ]
When non-fatal error like line-reset happens, ufshcd_err_handler() starts
to abort tasks by ufshcd_try_to_abort_task(). When it tries to issue a task
management request, we hit two warnings:
WARNING: CPU: 7 PID: 7
On Fri, 22 Jan 2021, shuo.a@intel.com wrote:
From: Shuo Liu
An I/O request of a User VM, which is constructed by the hypervisor, is
distributed by the ACRN Hypervisor Service Module to an I/O client
corresponding to the address range of the I/O request.
For each User VM
On 1/19/21 5:33 AM, Pan Bian wrote:
> Free the request rq before returning error code.
Applied, thanks.
--
Jens Axboe
On Sun, Jan 24, 2021 at 01:49:38PM +0200, Tomas Winkler wrote:
> From: Alexander Usyskin
>
> The MEI bus has a special behavior on suspend it destroys
> all the attached devices, this is due to the fact that also
> firmware context is not persistent across power flows.
>
> If watchdog on MEI
From: Alexander Usyskin
The MEI bus has a special behavior on suspend it destroys
all the attached devices, this is due to the fact that also
firmware context is not persistent across power flows.
If watchdog on MEI bus is ticking before suspending the firmware
times out and reports that the OS
>
> Tomas,
>
> On Thu, Jan 07, 2021 at 04:12:15PM -0800, Guenter Roeck wrote:
> > Hi,
> >
> > On Thu, Jan 07, 2021 at 09:57:30PM +0200, Tomas Winkler wrote:
> > > From: Alexander Usyskin
> > >
> > > Send the stop command to the firmware on watchdog unregister to
> > > eleminate false event on
The pull request you sent on Sat, 23 Jan 2021 13:43:29 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-current
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/077e81d51d1fce056b361c27b6cddd41e1469b9d
Thank you!
--
Deet-doot-dot, I
Tomas,
On Thu, Jan 07, 2021 at 04:12:15PM -0800, Guenter Roeck wrote:
> Hi,
>
> On Thu, Jan 07, 2021 at 09:57:30PM +0200, Tomas Winkler wrote:
> > From: Alexander Usyskin
> >
> > Send the stop command to the firmware on watchdog unregister
> > to eleminate false event on suspend.
> >
>
>
Linus,
I2C has another bunch of driver fixes. Please pull.
Thanks,
Wolfram
The following changes since commit 7c53f6b671f4aba70ff15e1b05148b10d58c2837:
Linux 5.11-rc3 (2021-01-10 14:34:50 -0800)
are available in the Git repository at:
Hello,
syzbot found the following issue on:
HEAD commit:7d68e382 bpf: Permit size-0 datasec
git tree: bpf-next
console output: https://syzkaller.appspot.com/x/log.txt?x=17a5a184d0
kernel config: https://syzkaller.appspot.com/x/.config?x=e0c7843b8af99dff
dashboard link:
From: Andrey Zhizhikin
[ Upstream commit e56b3d94d939f52d46209b9e1b6700c5bfff3123 ]
MSFT ActiveSync implementation requires that the size of the response for
incoming query is to be provided in the request input length. Failure to
set the input size proper results in failed request transfer
From: Andrey Zhizhikin
[ Upstream commit e56b3d94d939f52d46209b9e1b6700c5bfff3123 ]
MSFT ActiveSync implementation requires that the size of the response for
incoming query is to be provided in the request input length. Failure to
set the input size proper results in failed request transfer
From: Andrey Zhizhikin
[ Upstream commit e56b3d94d939f52d46209b9e1b6700c5bfff3123 ]
MSFT ActiveSync implementation requires that the size of the response for
incoming query is to be provided in the request input length. Failure to
set the input size proper results in failed request transfer
From: Andrey Zhizhikin
[ Upstream commit e56b3d94d939f52d46209b9e1b6700c5bfff3123 ]
MSFT ActiveSync implementation requires that the size of the response for
incoming query is to be provided in the request input length. Failure to
set the input size proper results in failed request transfer
From: Andrey Zhizhikin
[ Upstream commit e56b3d94d939f52d46209b9e1b6700c5bfff3123 ]
MSFT ActiveSync implementation requires that the size of the response for
incoming query is to be provided in the request input length. Failure to
set the input size proper results in failed request transfer
From: Andrey Zhizhikin
[ Upstream commit e56b3d94d939f52d46209b9e1b6700c5bfff3123 ]
MSFT ActiveSync implementation requires that the size of the response for
incoming query is to be provided in the request input length. Failure to
set the input size proper results in failed request transfer
From: Shuo Liu
An I/O request of a User VM, which is constructed by the hypervisor, is
distributed by the ACRN Hypervisor Service Module to an I/O client
corresponding to the address range of the I/O request.
For each User VM, there is a shared 4-KByte memory region used for I/O
requests
Add the missing device-recipient define to the vendor control requests
for completeness.
Signed-off-by: Johan Hovold
---
drivers/usb/serial/xr_serial.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/serial/xr_serial.c b/drivers/usb/serial/xr_serial.c
After commit "40d09b53bfc557af7481b9d80f060a7ac9c7d314", request is
completed in softirq. This may cause the system to suffer bad preemptoff
time.
The mmc driver has its own complete workqueue, but it can not work
well now.
The REQ_HIPRI flag can be used to complete request directly
On Wed, Jan 20, 2021 at 10:15:22AM +0800, Liu Xiang wrote:
> The commit "40d09b53bfc557af7481b9d80f060a7ac9c7d314" has solved the
> irqsoff problem by completing the request in softirq. But it may cause
> the system to suffer bad preemptoff time.
> Introduce th
Current task management request send/compl implementation is broken, the
problems and fixes are listed as below:
Problem: TMR completion timeout. ufshcd_tmc_handler() calls
blk_mq_tagset_busy_iter(fn == ufshcd_compl_tm()), but since
blk_mq_tagset_busy_iter() only iterates over
On 01/20, Can Guo wrote:
> Current task management request send/compl implementation is broken, the
> problems and fixes are listed as below:
>
> Problem: TMR completion timeout. ufshcd_tmc_handler() calls
> blk_mq_tagset_busy_iter(fn == ufshcd_compl_t
Commit 5c0a85fad949 ("mm: make faultaround produce old ptes") changed
the "faultaround" behaviour to initialise prefaulted PTEs as 'old',
since this avoids vmscan wrongly assuming that they are hot, despite
having never been explicitly accessed by userspace. The change has been
shown to benefit
On Tue, Jan 19, 2021 at 04:33:11AM -0800, Pan Bian wrote:
> Free the request rq before returning error code.
>
> Fixes: 972248e9111e ("scsi: bsg-lib: handle bidi requests without block layer
> help")
> Signed-off-by: Pan Bian
Looks good,
Reviewed-by: Christoph Hellwig
Current task management request send/compl implementation is broken, the
problems and fixes are listed as below:
Problem: TMR completion timeout. ufshcd_tmc_handler() calls
blk_mq_tagset_busy_iter(fn == ufshcd_compl_tm()), but since
blk_mq_tagset_busy_iter() only iterates over
On Wed, Jan 20, 2021 at 10:15:22AM +0800, Liu Xiang wrote:
> The commit "40d09b53bfc557af7481b9d80f060a7ac9c7d314" has solved the
> irqsoff problem by completing the request in softirq. But it may cause
> the system to suffer bad preemptoff time.
> Introduce th
The commit "40d09b53bfc557af7481b9d80f060a7ac9c7d314" has solved the
irqsoff problem by completing the request in softirq. But it may cause
the system to suffer bad preemptoff time.
Introduce the REQ_COMPLETE_WQ flag and blk_complete workqueue.
This flag makes the request to be
Free the request rq before returning error code.
Fixes: 972248e9111e ("scsi: bsg-lib: handle bidi requests without block layer
help")
Signed-off-by: Pan Bian
---
block/bsg.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/block/bsg.c b/block/bsg.c
index d7
ocesses IO
requests in interrupt/softirq context.
When Crypto API backlogs a crypto request, dm-crypt uses
wait_for_completion to avoid sending further requests to an already
overloaded crypto driver. However, if the code is executing in softirq
context, we might get the following stacktrace:
[ 210.2352
From: Trond Myklebust
commit 1757655d780d9d29bc4b60e708342e94924f7ef3 upstream.
In pnfs_generic_clear_request_commit(), we try calling
pnfs_free_bucket_lseg() before we remove the request from the DS bucket.
That will always fail, since the point is to test for whether or not
that bucket
hid = cpu_to_le64(arch_id),
+ };
+
+ if (viommu_send_req_sync(vdomain->viommu, , sizeof(req)))
+ pr_debug("could not send invalidate request\n");
+}
+
+static void viommu_flush_tlb_add(struct iommu_iotlb_gather *gather,
+unsigned l
Create an irq mapping for the hw_irq number provided from phyp firmware.
Request an irq assigned our Sub-CRQ interrupt handler. Unmap these irqs
at Sub-CRQ teardown.
Signed-off-by: Tyrel Datwyler
Reviewed-by: Brian King
---
drivers/scsi/ibmvscsi/ibmvfc.c | 25 +
1 file
Commit 5c0a85fad949 ("mm: make faultaround produce old ptes") changed
the "faultaround" behaviour to initialise prefaulted PTEs as 'old',
since this avoids vmscan wrongly assuming that they are hot, despite
having never been explicitly accessed by userspace. The change has been
shown to benefit
Hi developers,
I found the following cases should share the same root cause:
BUG: unable to handle kernel paging request in bpf_trace_run1
BUG: unable to handle kernel paging request in bpf_trace_run2
BUG: unable to handle kernel paging request in bpf_trace_run3
BUG: unable to handle kernel
On Tue, 12 Jan 2021, Shuo A Liu wrote:
On Mon 11.Jan'21 at 13:52:19 -0800, Davidlohr Bueso wrote:
Could this not be done in process context instead?
It could be. The original consideration with tasklet was more about
performance as the I/O requests dispatching is a hot code path. I think
irq
On Mon 11.Jan'21 at 13:52:19 -0800, Davidlohr Bueso wrote:
On Wed, 06 Jan 2021, shuo.a@intel.com wrote:
The processing flow of I/O requests are listed as following:
a) The I/O handler of the hypervisor will fill an I/O request with
PENDING state when a trapped I/O access happens in a User
Hello:
This patch was applied to netdev/net.git (refs/heads/master):
On Fri, 8 Jan 2021 09:58:39 + you wrote:
> MSFT ActiveSync implementation requires that the size of the response for
> incoming query is to be provided in the request input length. Failure to
> set the input si
Create an irq mapping for the hw_irq number provided from phyp firmware.
Request an irq assigned our Sub-CRQ interrupt handler. Unmap these irqs
at Sub-CRQ teardown.
Signed-off-by: Tyrel Datwyler
---
drivers/scsi/ibmvscsi/ibmvfc.c | 25 +
1 file changed, 25 insertions
On Wed, 06 Jan 2021, shuo.a@intel.com wrote:
The processing flow of I/O requests are listed as following:
a) The I/O handler of the hypervisor will fill an I/O request with
PENDING state when a trapped I/O access happens in a User VM.
b) The hypervisor makes an upcall, which
On Mon, Jan 11, 2021 at 02:37:42PM +, Will Deacon wrote:
> On Mon, Jan 11, 2021 at 05:25:33PM +0300, Kirill A. Shutemov wrote:
> > On Fri, Jan 08, 2021 at 05:15:16PM +, Will Deacon wrote:
> > > diff --git a/mm/filemap.c b/mm/filemap.c
> > > index c1f2dc89b8a7..0fb9d1714797 100644
> > > ---
On Mon, Jan 11, 2021 at 05:25:33PM +0300, Kirill A. Shutemov wrote:
> On Fri, Jan 08, 2021 at 05:15:16PM +, Will Deacon wrote:
> > diff --git a/mm/filemap.c b/mm/filemap.c
> > index c1f2dc89b8a7..0fb9d1714797 100644
> > --- a/mm/filemap.c
> > +++ b/mm/filemap.c
> > @@ -3051,14 +3051,18 @@
301 - 400 of 18873 matches
Mail list logo
