It isn't necessary to check the host depth in scsi_queue_rq() any more
since it has been respected by blk-mq before calling scsi_queue_rq() via
getting driver tag.
Lots of LUNs may attach to same host, and per-host IOPS may reach millions
level, so we should avoid to this expensive atomic operatio
From: Colin Ian King
In the case when the phy_mask is bitwise anded with the
phy_index bit is zero the continue statement currently jumps
to the next iteration of the while loop and phy_index is
never actually incremented, potentially causing an infinite
loop if phy_index is less than SCI_MAX_PHS
On Fri, 2018-04-20 at 10:03 +0100, Colin King wrote:
> From: Colin Ian King
>
> In the case when the phy_mask is bitwise anded with the
> phy_index bit is zero the continue statement currently jumps
> to the next iteration of the while loop and phy_index is
> never actually incremented, potential
On Thu, 2018-04-19 at 15:10 -0700, Anatoliy Glagolev wrote:
> Updated: rebased on recent Linux, cc-ed maintainers per instructions
> in MAINTAINERS file
>
> From df939b80d02bf37b21efaaef8ede86cfd39b0cb8 Mon Sep 17 00:00:00
> 2001
> From: Anatoliy Glagolev
> Date: Thu, 19 Apr 2018 15:06:06 -0600
>
From: Colin Ian King
In the case when the phy_mask is bitwise anded with the
phy_index bit is zero the continue statement currently jumps
to the next iteration of the while loop and phy_index is
never actually incremented, potentially causing an infinite
loop if phy_index is less than SCI_MAX_PHS
On 20/04/18 10:45, James Bottomley wrote:
> On Fri, 2018-04-20 at 10:03 +0100, Colin King wrote:
>> From: Colin Ian King
>>
>> In the case when the phy_mask is bitwise anded with the
>> phy_index bit is zero the continue statement currently jumps
>> to the next iteration of the while loop and phy_
https://bugzilla.kernel.org/show_bug.cgi?id=199435
--- Comment #7 from Anthony Hausman (anthonyhaussm...@gmail.com) ---
I had a similar stack trace:
Apr 20 14:57:18 kernel: INFO: task jbd2/sdt-8:10890 blocked for more than 120
seconds.
Apr 20 14:57:18 kernel: Tainted: G OE 4.11.
On Thu, 19 Apr 2018 14:54:24 -0700
Long Li wrote:
> From: Long Li
>
> This is a best effort for estimating on how busy the ring buffer is for
> that channel, based on available buffer to write in percentage. It is still
> possible that at the time of actual ring buffer write, the space may not
do_gettimeofday() is deprecated because of the y2038 overflow.
Here, we use the result to pass into a 32-bit field in the firmware,
which still risks an overflow, but if the firmware is written
to expect unsigned values, it can at least last until y2106,
and there is not much we can do about it.
T
do_gettimeofday() is deprecated since it will stop working in 2038 on
32-bit platforms, leading to incorrect times passed to the firmware.
On 64-bit platforms the current code appears to be fine, as the
calculation passes an 8-bit century number into the firmware that can
represent times long in th
Long,
> If num_cpus=1, we don't have any sub channels.
>
> The host offers one sub channel for VM with 5 CPUs, after that it offers
> an additional sub channel every 4 CPUs.
>
> The primary channel is always offered.
Applied to 4.17/scsi-fixes. Thanks!
--
Martin K. Petersen Oracle Linux E
Long,
> This is a best effort for estimating on how busy the ring buffer is
> for that channel, based on available buffer to write in percentage. It
> is still possible that at the time of actual ring buffer write, the
> space may not be available due to other processes may be writing at
> the ti
On Thu, Apr 19, 2018 at 2:32 AM, Paolo Valente wrote:
> I'm missing something here. When the request gets completed in the
> first place, the hook bfq_finish_requeue_request gets called, and that
> hook clears both ->elv.priv elements (as the request has a non-null
> elv.icq). So, when bfq gets
Hi.
On 20.04.2018 22:23, Kees Cook wrote:
I don't know the "how", I only found the "what". :) If you want, grab
the reproducer VM linked to earlier in this thread; it'll hit the
problem within about 30 seconds of running the reproducer.
Just to avoid a possible confusion I should note that I'v
Chaitra,
A few comments:
> @@ -426,7 +427,7 @@ static void _clone_sg_entries(struct MPT3SAS_ADAPTER *ioc,
> dst_addr_phys = _base_get_chain_phys(ioc,
> smid, sge_chain_count);
> WARN_ON(dst_addr_phys > U32_
Jia-Ju,
> st_probe() is never called in atomic context.
Applied patches 1 and 2 to 4.18/scsi-queue. Thanks!
--
Martin K. Petersen Oracle Linux Engineering
> This patch isn't applyable because your mailer has changed all the tabs
> to spaces.
>
> I also think there's no need to do it this way. I think what we need
> is for fc_bsg_remove() to wait until the bsg queue is drained. It does
> look like the author thought this happened otherwise the co
Good day,
I am seeking your concept with great gratitude to present you as a
representative to carry out business transactions with a reasonable share upon
your interest and cooperation to work with us in trust. If interested please
get back.
Regards
Kingsley
---
This email has been checked
Randy,
> This patch series fixes kernel-doc warnings in drivers/target/ and its
> header files, then adds a Documentation driver-api chapter for target
> driver interfaces.
Applied to 4.18/scsi-queue. Thanks!
--
Martin K. Petersen Oracle Linux Engineering
Bryant,
> The bug exists in the memcmp in which the length passed in must be
> guaranteed to be 1. This bug currently exists because the second
> pointer passed in, can be smaller than the cmd->data_length, which
> causes a fortify_panic.
>
> The fix is to use memchr_inv instead to find whether o
Martin,
> Here is another attempt to handle the special return codes for ABORTED
> COMMAND for certain SCSI devices. Following MKP's recommendation, I've
> created two new BLIST flags, simplifying the code in scsi_error.c
> compared to the previous versions. Rather than using "free" bits, I
> inc
Colin,
> In the case when the phy_mask is bitwise anded with the phy_index bit
> is zero the continue statement currently jumps to the next iteration
> of the while loop and phy_index is never actually incremented,
> potentially causing an infinite loop if phy_index is less than
> SCI_MAX_PHS. Fi
YueHaibing,
> Remove boilerplate code by using macro module_pci_driver.
Applied to 4.18/scsi-queue. Thank you!
--
Martin K. Petersen Oracle Linux Engineering
Arnd,
> do_gettimeofday() is deprecated because of the y2038 overflow. Here,
> we use the result to pass into a 32-bit field in the firmware, which
> still risks an overflow, but if the firmware is written to expect
> unsigned values, it can at least last until y2106, and there is not
> much we
Arnd,
> do_gettimeofday() is deprecated since it will stop working in 2038 on
> 32-bit platforms, leading to incorrect times passed to the firmware.
> On 64-bit platforms the current code appears to be fine, as the
> calculation passes an 8-bit century number into the firmware that can
> represen
Johannes,
> here's a early preview of my SCSI results rework so we can eventually
> discuss things next week at LSF/MM (it still has compiler errors on
> aic7xxx and scsi_debug).
Here's what I'd like to see:
- Forget about cramming everything into that dreaded u32 result. Bart's
suggestion
The vmw_pvscsi driver returns DID_ABORT for commands aborted internally
by the adapter, leading to the filesystem going read-only. Change the
result to DID_BUS_BUSY, causing the kernel to retry the command.
Signed-off-by: Jim Gill
---
drivers/scsi/vmw_pvscsi.c | 2 +-
1 file changed, 1 insertion
The vmw_pvscsi driver returns DID_ABORT for commands aborted internally
by the adapter, leading to the filesystem going read-only. Change the
result to DID_BUS_BUSY, causing the kernel to retry the command.
Signed-off-by: Jim Gill
---
drivers/scsi/vmw_pvscsi.c | 2 +-
1 file changed, 1 insertion
28 matches
Mail list logo
