On Tue, 2018-07-31 at 01:35 -0400, Sreekanth Reddy wrote:
> In mpt3sas_base_clear_st() function smid value is reseted in wrong line,
> i.e. driver should reset smid value to zero after decrementing chain_offset
> counter in chain_lookup table but in current code, driver is resetting smid
> value
Arjun,
> - Updates csio_get_flash_params() to take care of ISSI, Macronix and
> Winbond FLASH parts.
>
> - Assume flash part size to be 4MB if it cannot be identified
Applied to 4.19/scsi-queue, thanks!
--
Martin K. Petersen Oracle Linux Engineering
}
if (vha->vp_idx) {
diff --git a/drivers/scsi/qla2xxx/qla_mbx.c b/drivers/scsi/qla2xxx/qla_mbx.c
index 7e875f575229..4e42ce057a37 100644
--- a/drivers/scsi/qla2xxx/qla_mbx.c
+++ b/drivers/scsi/qla2xxx/qla_mbx.c
@@ -2177,7 +2177,10 @@ qla2x00_lip_reset(scsi_qla_hos
On Thu, 2018-08-02 at 16:11 -0400, Martin K. Petersen wrote:
> > In mpt3sas_base_clear_st() function smid value is reseted in wrong
> > line, i.e. driver should reset smid value to zero after decrementing
> > chain_offset counter in chain_lookup table but in current code, driver
> > is resetting
Andy,
Please review the changes Sreekanth made to address your feedback.
> Swap the I/O memory read value back to cpu endianness before storing it
> in a data structures which are defined in the MPI headers where
> u8 components are not defined in the endianness order.
>
> In this area from
Bart,
> In mpt3sas_base_clear_st() function smid value is reseted in wrong
> line, i.e. driver should reset smid value to zero after decrementing
> chain_offset counter in chain_lookup table but in current code, driver
> is resetting smid value before decrementing the chain_offset
> counter.
James,
> This patch contains lpfc bug fixes
Applied to 4.19/scsi-queue, thank you!
--
Martin K. Petersen Oracle Linux Engineering
Bart,
> This patch series avoids that SCSI device removal through sysfs triggers a
> deadlock. Please consider this patch series for the v4.19 kernel.
Applied to 4.19/scsi-queue, thanks!
--
Martin K. Petersen Oracle Linux Engineering
Mike,
> The following patches were made over Martin's for-next branch. They are
> the patches from my session RFC patchset that were reviewed by Bart and
> Christoph and are fixes/cleanups that I think are ok changes in general.
Applied to 4.19/scsi-queue. Thanks!
--
Martin K. Petersen
On Wed, 2018-08-01 at 22:58 +, Bart Van Assche wrote:
> On Wed, 2018-08-01 at 21:16 +, Bart Van Assche wrote:
> > During my kernel tests of today I noticed that this patch makes booting
> > significantly slower: boot time for a VM increases from 6s to 157s. Martin,
> > please drop this
nayak Holikatti ; Avi Shchislowski ; Alex Lemberg ; Stanislav Nijnikov ;
> subha...@codeaurora.org
> Subject: Re: [PATCH 6/6] scsi: ufs-bsg: Add support for uic commands in
> ufs_bsg_request()
>
> On Wed, 2018-08-01 at 11:04 +0300, Avri Altman wrote:
> > + st
On Thu, 2018-08-02 at 11:05 +, Avri Altman wrote:
> -Original Message-
> > From: Bart Van Assche
> > Sent: Wednesday, August 01, 2018 6:28 PM
> > [ ... ]
> > > + spin_unlock_irqrestore(host->host_lock, flags);
> > > +
> > > + /* wait until the task management command is completed */
>
nayak Holikatti ; Avi Shchislowski ; Alex Lemberg ; Stanislav Nijnikov ;
> subha...@codeaurora.org
> Subject: Re: [PATCH 5/6] scsi: ufs-bsg: Add support for raw upiu in
> ufs_bsg_request()
>
> On Wed, 2018-08-01 at 11:04 +0300, Avri Altman wrote:
> > + if (qr->opcode != UPIU_QUE
nayak Holikatti ; Avi Shchislowski ; Alex Lemberg ; Stanislav Nijnikov ;
> subha...@codeaurora.org
> Subject: Re: [PATCH 4/6] scsi: ufs: Add API to execute raw upiu commands
>
> On Wed, 2018-08-01 at 11:04 +0300, Avri Altman wrote:
> > +/**
> > + * ufshcd_exec_raw_upiu_cmd -
nayak Holikatti ; Avi Shchislowski ; Alex Lemberg ; Stanislav Nijnikov ;
> subha...@codeaurora.org
> Subject: Re: [PATCH 4/6] scsi: ufs: Add API to execute raw upiu commands
>
> On Wed, 2018-08-01 at 11:04 +0300, Avri Altman wrote:
> > + wait_event(hba->tm_tag_wq, ufshcd_get_t
Cc: Vinayak Holikatti ; Avi Shchislowski ; Alex Lemberg ; Stanislav Nijnikov ;
> subha...@codeaurora.org
> Subject: Re: [PATCH 2/6] scsi: ufs: Add ufs-bsg module
>
> On Wed, 2018-08-01 at 11:04 +0300, Avri Altman wrote:
> > +++ b/drivers/scsi/ufs/ufs_bsg.c
> > @@ -0,0 +1,12
On Mon, Jul 30, 2018 at 11:40:51AM -0700, Bart Van Assche wrote:
> Introduce these two functions and export them such that the next patch
> can add calls to these functions from the SCSI core.
>
> Signed-off-by: Bart Van Assche
> Cc: Greg Kroah-Hartman
> Cc: Tejun Heo
> Cc:
> ---
>
On Thu, Aug 02, 2018 at 07:15:30AM +0800, Ming Lei wrote:
> I just checked my daily test log, looks this issue is reported 1st time
> on next-20180731.
>From the diff between next-20180727 and next-20180731 in drivers/scsi
nothing really sticks out.
$ PAGER= git diff --stat
On Wed, Aug 01, 2018 at 02:06:11PM +0200, Johannes Thumshirn wrote:
> On Wed, Aug 01, 2018 at 08:00:44PM +0800, Ming Lei wrote:
> > On Wed, Aug 01, 2018 at 07:52:19PM +0800, Ming Lei wrote:
> > > On Wed, Aug 01, 2018 at 12:24:00PM +0100, Matt Hart wrote:
> > > > On 1 August 2018 at 11:59, Mark
On Wed, 2018-08-01 at 21:16 +, Bart Van Assche wrote:
> During my kernel tests of today I noticed that this patch makes booting
> significantly slower: boot time for a VM increases from 6s to 157s. Martin,
> please drop this patch series.
Please ignore my previous message - these two patches
On Mon, 2018-07-30 at 11:40 -0700, Bart Van Assche wrote:
> A long time ago the unfortunate decision was taken to add a self-
> deletion attribute to the sysfs SCSI device directory. That decision
> was unfortunate because self-deletion is really tricky. We can't drop
> that attribute because
On Mon, 2018-07-30 at 14:52 -0400, Douglas Gilbert wrote:
> I designed 'struct sg_io_v4' found in include/uapi/linux/bsg.h to handle
> storage
> related protocols, not just the SCSI command set. After the guard, the next
> two fields in that structure are:
> __u32 protocol; /*
On Wed, 2018-08-01 at 11:44 -0500, Mike Christie wrote:
> I agree knowing the acl info is useful, so how about the following:
>
> 1. Create a file named "acl" in the session's dir.
> 2. For dynamic_node_acl=0 the acl file will return a empty string or
> "generate_node_acls=1" or "demo mode
On 08/01/2018 11:44 AM, Mike Christie wrote:
> 1. Create a file named "acl" in the session's dir.
> 2. For dynamic_node_acl=0 the acl file will return a empty string or
Miswrote this.
Above should be dynamic_node_acl=1
> "generate_node_acls=1" or "demo mode enabled".
> 3. For dynamic_node_acl=1
On 07/19/2018 12:07 PM, Bart Van Assche wrote:
> On Thu, 2018-07-19 at 11:38 -0500, Mike Christie wrote:
>> On 07/19/2018 10:37 AM, Bart Van Assche wrote:
>>> The general recommendation for configfs is that each attribute contains a
>>> single value, just like for sysfs. Patch 11/15 exports two
On Mon, Jul 30, 2018 at 11:40:52AM -0700, Bart Van Assche wrote:
> A long time ago the unfortunate decision was taken to add a self-
> deletion attribute to the sysfs SCSI device directory. That decision
> was unfortunate because self-deletion is really tricky. We can't drop
> that attribute
On Mon, Jul 30, 2018 at 11:40:51AM -0700, Bart Van Assche wrote:
> Introduce these two functions and export them such that the next patch
> can add calls to these functions from the SCSI core.
>
> Signed-off-by: Bart Van Assche
> Cc: Greg Kroah-Hartman
> Cc: Tejun Heo
> Cc:
Acked-by: Tejun
On Wed, 2018-08-01 at 11:04 +0300, Avri Altman wrote:
> + struct uic_command uc = {0};
Please use "{ }" or "{}" for structure initialization as is done elsewhere in
the kernel instead of "{0}".
> +#define UIC_CMD_SIZE (sizeof(u32) * 4)
Please add a comment above this definition that
On Wed, 2018-08-01 at 11:04 +0300, Avri Altman wrote:
> + if (qr->opcode != UPIU_QUERY_OPCODE_WRITE_DESC ||
> + desc_size <= 0)
> + return -EINVAL;
Please use the full line length and don't split lines if that is not necessary.
> + ret =
On Wed, 2018-08-01 at 11:04 +0300, Avri Altman wrote:
> +/**
> + * ufshcd_exec_raw_upiu_cmd - API function for sending raw upiu commands
> + * @hba: per-adapter instance
> + * @req_upiu:upiu request - 8 dwards
> + * @rsp_upiu:upiu reply - 8 dwards
> + * @msgcode: message code,
On Wed, 2018-08-01 at 11:04 +0300, Avri Altman wrote:
> + wait_event(hba->tm_tag_wq, ufshcd_get_tm_free_slot(hba, _slot));
The above is the weirdest API I have seen so far for tag allocation.
Why does ufshcd_get_tm_free_slot() does a linear search through a bitmap
instead of using the sbitmap
On Wed, 2018-08-01 at 11:04 +0300, Avri Altman wrote:
> +++ b/drivers/scsi/ufs/ufs_bsg.c
> @@ -0,0 +1,127 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * SSCSI transport companion for UFS HBA
What is "SSCSI"?
> diff --git a/drivers/scsi/ufs/ufs_bsg.h b/drivers/scsi/ufs/ufs_bsg.h
> new file
an Assche ; James E.J. Bottomley
> ; Martin K. Petersen
> ; linux-scsi@vger.kernel.org; Stanislav
> Nijnikov ; Avi Shchislowski
> ; Alex Lemberg ;
> Subhash Jadavani ; Vinayak Holikatti
>
> Subject: Re: [PATCH 1/6] scsi: Add ufs transport class
>
> Hi Avri,
>
>
On Wed, Aug 01, 2018 at 02:50:40PM +0100, Guillaume Tucker wrote:
>
> Sure, although it didn't make any apparent difference, still on
> next-20180731:
>
> https://lava.collabora.co.uk/scheduler/job/1215417
>
> The .config file I used is available here, with just
> CONFIG_BLK_DEV_RAM=y on
On 01/08/18 13:40, Johannes Thumshirn wrote:
On Wed, Aug 01, 2018 at 01:37:17PM +0100, Guillaume Tucker wrote:
The kernel images I used have the git revision in their file name
to make it clear where they came from, they were built with
x86_64_defconfig. The links to the kernel and ramdisks
On 01/08/18 12:25, Johannes Thumshirn wrote:
On Wed, Aug 01, 2018 at 11:59:19AM +0100, Mark Brown wrote:
On Wed, Aug 01, 2018 at 06:51:09PM +0800, Ming Lei wrote:
You may have to provide some clue, such as dmesg log, boot disk, ...
I guess you don't use virtio-scsi/virtio-blk since both
On Wed, Aug 01, 2018 at 08:00:44PM +0800, Ming Lei wrote:
> On Wed, Aug 01, 2018 at 07:52:19PM +0800, Ming Lei wrote:
> > On Wed, Aug 01, 2018 at 12:24:00PM +0100, Matt Hart wrote:
> > > On 1 August 2018 at 11:59, Mark Brown wrote:
> > > > On Wed, Aug 01, 2018 at 06:51:09PM +0800, Ming Lei wrote:
On Wed, Aug 01, 2018 at 07:52:19PM +0800, Ming Lei wrote:
> On Wed, Aug 01, 2018 at 12:24:00PM +0100, Matt Hart wrote:
> > On 1 August 2018 at 11:59, Mark Brown wrote:
> > > On Wed, Aug 01, 2018 at 06:51:09PM +0800, Ming Lei wrote:
> > >
> > >> You may have to provide some clue, such as dmesg
On Wed, Aug 01, 2018 at 07:52:21PM +0800, Ming Lei wrote:
> On Wed, Aug 01, 2018 at 12:24:00PM +0100, Matt Hart wrote:
> > On 1 August 2018 at 11:59, Mark Brown wrote:
> > > On Wed, Aug 01, 2018 at 06:51:09PM +0800, Ming Lei wrote:
> > >
> > >> You may have to provide some clue, such as dmesg
On Wed, Aug 01, 2018 at 12:24:00PM +0100, Matt Hart wrote:
> On 1 August 2018 at 11:59, Mark Brown wrote:
> > On Wed, Aug 01, 2018 at 06:51:09PM +0800, Ming Lei wrote:
> >
> >> You may have to provide some clue, such as dmesg log, boot disk, ...
> >
> >> I guess you don't use
On Wed, Aug 01, 2018 at 12:24:00PM +0100, Matt Hart wrote:
> And a full LAVA boot log from my lab
> http://lava.streamtester.net/scheduler/job/138067
>
> QEMU command line here:
> http://lava.streamtester.net/scheduler/job/138067#L75
>
> And a LAVA job definition, which includes the url of the
On Wed, Aug 01, 2018 at 08:33:23AM +0200, Hannes Reinecke wrote:
> On 07/31/2018 05:07 PM, Varun Prakash wrote:
> > If number of interrupt vectors are more than num_online_cpus()
> > then pci_alloc_irq_vectors_affinity() assigns cpumask based
> > on num_possible_cpus() to the remaining vectors
On Wed, Aug 01, 2018 at 11:59:19AM +0100, Mark Brown wrote:
> On Wed, Aug 01, 2018 at 06:51:09PM +0800, Ming Lei wrote:
>
> > You may have to provide some clue, such as dmesg log, boot disk, ...
>
> > I guess you don't use virtio-scsi/virtio-blk since both run at blk-mq
> > mode at default, even
On 1 August 2018 at 11:59, Mark Brown wrote:
> On Wed, Aug 01, 2018 at 06:51:09PM +0800, Ming Lei wrote:
>
>> You may have to provide some clue, such as dmesg log, boot disk, ...
>
>> I guess you don't use virtio-scsi/virtio-blk since both run at blk-mq
>> mode at default, even though without
Hi Avri,
On Wed, Aug 01, 2018 at 11:04:27AM +0300, Avri Altman wrote:
[...
> +#include
Why do you include bsg.h here and bsg-lib.h in the scsi_transport_ufs.h?
[...]
> +#define to_ufs_internal(tmpl)container_of(tmpl, struct ufs_internal,
> t)
I'd personally prefer this to be a
On Wed, Aug 01, 2018 at 06:51:09PM +0800, Ming Lei wrote:
> You may have to provide some clue, such as dmesg log, boot disk, ...
> I guess you don't use virtio-scsi/virtio-blk since both run at blk-mq
> mode at default, even though without d5038a13eca72fb.
Boot logs and so on can be found here:
On Wed, Aug 01, 2018 at 11:33:03AM +0100, Mark Brown wrote:
> On Wed, Aug 01, 2018 at 11:05:36AM +0100, Guillaume Tucker wrote:
> > On 31/07/18 16:14, kernelci.org bot wrote:
>
> > > Boot Regressions Detected:
> > [...]
> > > x86:
> > >
> > > x86_64_defconfig:
> > > qemu:
> > >
On Wed, Aug 01, 2018 at 11:05:36AM +0100, Guillaume Tucker wrote:
> On 31/07/18 16:14, kernelci.org bot wrote:
> > Boot Regressions Detected:
> [...]
> > x86:
> >
> > x86_64_defconfig:
> > qemu:
> > lab-baylibre: failing since 1 day (last pass: next-20180727 -
> >
On 31/07/18 16:14, kernelci.org bot wrote:
next/master boot: 179 boots: 11 failed, 167 passed with 1 offline
(next-20180731)
Full Boot Summary:
https://kernelci.org/boot/all/job/next/branch/master/kernel/next-20180731/
Full Build Summary:
suse.de; martin.peter...@oracle.com;
> Avri Altman
> Cc: Vinayak Holikatti ; Avi Shchislowski
> ; Alex Lemberg ;
> Stanislav Nijnikov ; subha...@codeaurora.org
> Subject: Re: [RFC 0/6] scsi: scsi transport for ufs devices
>
> On 2018-07-30 02:13 PM, Hannes Reinecke wrote:
> &g
On 07/31/2018 05:07 PM, Varun Prakash wrote:
> If number of interrupt vectors are more than num_online_cpus()
> then pci_alloc_irq_vectors_affinity() assigns cpumask based
> on num_possible_cpus() to the remaining vectors because of
> this interrupt does not generate for these vectors.
>
> This
imer,
LOOP_DOWN_TIME);
- qla2x00_mark_all_devices_lost(vha, 1);
+ if (!N2N_TOPO(ha))
+ qla2x00_mark_all_devices_lost(vha, 1);
}
if (vha->vp_idx) {
dif
During remote port loss fault testing, the driver crashed
with the following trace:
general protection fault: [#1] SMP
RIP: ... lpfc_nvme_register_port+0x250/0x480 [lpfc]
Call Trace:
lpfc_nlp_state_cleanup+0x1b3/0x7a0 [lpfc]
lpfc_nlp_set_state+0xa6/0x1d0 [lpfc]
Hi,
On Tue, Jul 31, 2018 at 10:38:06AM +0200, Johannes Thumshirn wrote:
> So I've fixed one use-after-free and one memory leak, but the one you
> reported is still on the TODO list.
Wow, thanks...
> Long story short, I can reproduce it here and I'm working on it.
>
> Thanks for your patience,
On Fri, Jul 27, 2018 at 12:49:55AM +0200, ard wrote:
> Actually already got there from my arm dump, but they are different in
> backtrace.
> Anyway:
> root@antec:~# grep -c fc_rport_create kmemleak.txt
> 44
> So 44 * 512 bytes leaked in that path. And an extra thing: "it was leaked in"
> libfc
Hi Martin,
> On Jul 30, 2018, at 7:29 PM, Martin K. Petersen
> wrote:
>
> External Email
>
> Himanshu,
>
>> This patch series addresses issue with N2N connection for FCP and
>> FC-NVMe by moving login to state machine and handle various state
>> change.
>>
>> Please apply this series to
Arjun,
> + switch (density) {
> + case 0x14: /* 1MB */
> + size = 1 << 20;
> + break;
It seems a bit silly to have a switch statement for this. Why not just
do:
size = 1 << density;
?
> + case 0x15: /* 2MB
Mike,
> The first patch fixes a locking bug in the command setup path. The
> rest of the patches fix several bugs and cleanup the setup and
> configuration code paths.
Applied to 4.19/scsi-queue. Thanks!
--
Martin K. Petersen Oracle Linux Engineering
Bart,
> The two patches in this series suppress one gcc 8 compiler warning and
> one sparse warning. Please consider these for kernel v4.19.
Applied to 4.19/scsi-queue, thanks!
--
Martin K. Petersen Oracle Linux Engineering
Bart,
> Tell snprintf() to store at most 255 characters in the output buffer
> instead of 256. This patch avoids that smatch reports the following
> warning:
Applied to 4.18/scsi-fixes. Thank you!
--
Martin K. Petersen Oracle Linux Engineering
Himanshu,
> This patch series addresses issue with N2N connection for FCP and
> FC-NVMe by moving login to state machine and handle various state
> change.
>
> Please apply this series to 4.19/scsi-queue at your earliest.
Does not apply, patch #2 fails. Please resubmit, thanks!
--
Martin K.
Himanshu,
> In the case of IOCB QFull, Initiator code can leave behind a stale
> pointer to an SRB structure on the outstanding command array.
Applied to 4.18/scsi-fixes. Thanks!
--
Martin K. Petersen Oracle Linux Engineering
On 2018-07-30 02:13 PM, Hannes Reinecke wrote:
On 07/30/2018 08:01 PM, Bart Van Assche wrote:
On Sun, 2018-07-29 at 16:33 +0300, Avri Altman wrote:
Here is a proposal to use the scsi transport subsystem to manage
ufs devices.
scsi transport is a framework that allow to send scsi commands to
a
On 07/30/2018 08:01 PM, Bart Van Assche wrote:
On Sun, 2018-07-29 at 16:33 +0300, Avri Altman wrote:
Here is a proposal to use the scsi transport subsystem to manage
ufs devices.
scsi transport is a framework that allow to send scsi commands to
a non-scsi devices. Still, it is flexible enough
On Sun, 2018-07-29 at 16:33 +0300, Avri Altman wrote:
> Here is a proposal to use the scsi transport subsystem to manage
> ufs devices.
>
> scsi transport is a framework that allow to send scsi commands to
> a non-scsi devices. Still, it is flexible enough to allow
> sending non-scsi commands as
Hello,
On Mon, Jul 30, 2018 at 05:50:02PM +, Bart Van Assche wrote:
> On Mon, 2018-07-30 at 10:31 -0700, t...@kernel.org wrote:
> > On Mon, Jul 30, 2018 at 05:28:11PM +, Bart Van Assche wrote:
> > > It's not clear to me how the sysfs_break_active_protection() should obtain
> > > the
On Mon, 2018-07-30 at 10:31 -0700, t...@kernel.org wrote:
> On Mon, Jul 30, 2018 at 05:28:11PM +, Bart Van Assche wrote:
> > It's not clear to me how the sysfs_break_active_protection() should obtain
> > the struct kernfs_node pointer to the attribute. Calling that function
> > before
> >
Hello, Bart.
On Mon, Jul 30, 2018 at 05:28:11PM +, Bart Van Assche wrote:
> It's not clear to me how the sysfs_break_active_protection() should obtain
> the struct kernfs_node pointer to the attribute. Calling that function before
> device_remove_file_self() causes a double call to
>
On Mon, 2018-07-30 at 07:13 -0700, t...@kernel.org wrote:
> Also, wouldn't it be better to just expose sysfs_break/unbreak and
> then do sth like the following from scsi?
>
> kobject_get();
> sysfs_break_active_protection();
> do normal sysfs removal;
>
On Sun, Jul 29, 2018 at 04:03:41AM +, Bart Van Assche wrote:
> On Thu, 2018-07-26 at 06:35 -0700, Tejun Heo wrote:
> > Making removal asynchronous this way sometimes causes issues because
> > whether the user sees the device released or not is racy.
>
> Hello Tejun,
>
> How could this change
Hello, Bart.
On Thu, Jul 26, 2018 at 09:57:40PM +, Bart Van Assche wrote:
...
> @@ -440,11 +445,21 @@ bool sysfs_remove_file_self(struct kobject *kobj, const
> struct attribute *attr)
> return false;
>
> ret = kernfs_remove_self(kn);
> + if (ret && cb) {
> +
On Thu, 2018-07-26 at 06:35 -0700, Tejun Heo wrote:
> Making removal asynchronous this way sometimes causes issues because
> whether the user sees the device released or not is racy.
Hello Tejun,
How could this change cause any user-visible changes? My understanding is
that any work queued with
On 7/27/18, 2:40 AM, "Bart Van Assche" wrote:
>External Email
>
>Tell snprintf() to store at most 255 characters in the output buffer
>instead of 256. This patch avoids that smatch reports the following
>warning:
>
>drivers/scsi/qedi/qedi_main.c:891: qedi_get_boot_tgt_info() error:
>snprintf()
On Fri, Jul 27, 2018 at 12:49:55AM +0200, ard wrote:
> Hi,
>
> On Thu, Jul 26, 2018 at 05:05:37PM +0200, Johannes Thumshirn wrote:
> > On Thu, Jul 26, 2018 at 04:25:24PM +0200, ard wrote:
> > > The system itself is an exynos 5422 arm. It worked perfectly fine
> > > with 3.10 as an Initiator, now
Hi,
On Thu, Jul 26, 2018 at 05:05:37PM +0200, Johannes Thumshirn wrote:
> On Thu, Jul 26, 2018 at 04:25:24PM +0200, ard wrote:
> > The system itself is an exynos 5422 arm. It worked perfectly fine
> > with 3.10 as an Initiator, now it leaks memory the moment I
> > enable the FCoE vlan on the
On Thu, 2018-07-26 at 07:14 -0700, t...@kernel.org wrote:
> Hello,
>
> On Thu, Jul 26, 2018 at 02:09:41PM +, Bart Van Assche wrote:
> > On Thu, 2018-07-26 at 06:35 -0700, Tejun Heo wrote:
> > > Making removal asynchronous this way sometimes causes issues because
> > > whether the user sees
On Thu, Jul 26, 2018 at 04:25:24PM +0200, ard wrote:
> The system itself is an exynos 5422 arm. It worked perfectly fine
> with 3.10 as an Initiator, now it leaks memory the moment I
> enable the FCoE vlan on the port.
So I had a look through the commits between v3.10 and v4.14 and this
one
On Thu, Jul 26, 2018 at 04:25:24PM +0200, ard wrote:
> > Anyways, can you please enable the kernel memory leak detector [1] and
> > possibly even try a more up to date (like v4.18-rc6) kernel?
> >
> > [1] https://www.kernel.org/doc/html/v4.17/dev-tools/kmemleak.html
>
> The up to date kernel
Hi,
On Thu, Jul 26, 2018 at 03:36:22PM +0200, Johannes Thumshirn wrote:
> On Thu, Jul 26, 2018 at 03:02:14PM +0200, ard wrote:
> > Hi Guys,
> >
> > I sent this to fcoe-devel but it might be holiday season or the
> > mailing list is abandoned as the emails concerning fcoe are
> > pretty low.
>
>
Hello,
On Thu, Jul 26, 2018 at 02:09:41PM +, Bart Van Assche wrote:
> On Thu, 2018-07-26 at 06:35 -0700, Tejun Heo wrote:
> > Making removal asynchronous this way sometimes causes issues because
> > whether the user sees the device released or not is racy.
> > kernfs/sysfs have mechanisms to
On Thu, 2018-07-26 at 06:35 -0700, Tejun Heo wrote:
> Making removal asynchronous this way sometimes causes issues because
> whether the user sees the device released or not is racy.
> kernfs/sysfs have mechanisms to deal with these cases - remove_self
> and kernfs_break_active_protection(). Have
On Thu, Jul 26, 2018 at 2:25 PM, Sreekanth Reddy
wrote:
> On Wed, Jul 25, 2018 at 8:32 PM, Andy Shevchenko
> wrote:
>> On Wed, Jul 25, 2018 at 12:42 PM, Sreekanth Reddy
>> wrote:
>>> Swap the I/O memory read value back to cpu endianness before storing it
>>> in a data structures which are
On Thu, Jul 26, 2018 at 03:02:14PM +0200, ard wrote:
> Hi Guys,
>
> I sent this to fcoe-devel but it might be holiday season or the
> mailing list is abandoned as the emails concerning fcoe are
> pretty low.
Yes, the list is defunct as I didn't get admin privileges passed by
the old Maintainer
Hello,
ISTR giving the same feedback before.
On Wed, Jul 25, 2018 at 10:38:28AM -0700, Bart Van Assche wrote:
> +struct remove_dev_work {
> + struct callback_headhead;
> + struct scsi_device *sdev;
> +};
> +
> +static void delete_sdev(struct callback_head *head)
> +{
> +
Bart Van Assche 于2018年7月25日周三 下午7:39写道：
>
> This patch avoids that self-removal triggers the following deadlock:
>
> ==
> WARNING: possible circular locking dependency detected
> 4.18.0-rc2-dbg+ #5 Not tainted
>
>From my limited insight into this:
Looks good,
Reviewed-by: Johannes Thumshirn
--
Johannes Thumshirn Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane
On Tue, Jul 24, 2018 at 10:37 AM, Sreekanth Reddy
wrote:
> Any update on this patch!.
Just Ping once again. Any update on this patch.
> Thanks,
> Sreekanth
>
> On Fri, Jul 20, 2018 at 5:56 PM, Sreekanth Reddy
> wrote:
>> In mpt3sas_base_clear_st() function smid value is reseted in wrong line,
On Wed, Jul 25, 2018 at 8:32 PM, Andy Shevchenko
wrote:
> On Wed, Jul 25, 2018 at 12:42 PM, Sreekanth Reddy
> wrote:
>> Swap the I/O memory read value back to cpu endianness before storing it
>> in a data structures which are defined in the MPI headers where
>> u8 components are not defined in
On 2018/7/24 3:07, Mike Christie wrote:
The following patches were made over Martin's for-next branch.
The first patch fixes a locking bug in the command setup path. The rest
of the patches fix several bugs and cleanup the setup and configuration
code paths.
It looks good to me.
This is also
Bart,
> This patch avoids that self-removal triggers the following deadlock:
Somebody please review this so we can get it merged.
--
Martin K. Petersen Oracle Linux Engineering
On Sat, 2018-07-21 at 01:10 -0400, Douglas Gilbert wrote:
> This patch is motivated by a response in the thread:
> Re: [PATCH 0/5]stop normal completion path entering a timeout req
> by Jianchao Wang . It generalizes the error injection of
> blk_abort_request() to use scsi_debug'
LOOP_DOWN_TIME);
- qla2x00_mark_all_devices_lost(vha, 1);
+ if (!N2N_TOPO(ha))
+ qla2x00_mark_all_devices_lost(vha, 1);
}
if (vha->vp_idx) {
diff --git a/drivers/scsi/qla2xxx/qla_mb
gt;hostt->eh_timed_out()? Can that cause a
> use-after-free
> in .eh_timed_out()? Can that cause .eh_timed_out() to return
> BLK_EH_RESET_TIMER
> when it should return BLK_EH_DONE? Can that cause blk_mq_rq_timed_out() to
> call
> blk_add_timer() when that function shouldn't be cal
On Wed, Jul 25, 2018 at 8:55 AM Jessica Yu wrote:
>
> +++ Martijn Coenen [24/07/18 09:56 +0200]:
> >I did find an issue with my approach:
> >
> >On Mon, Jul 16, 2018 at 2:21 PM, Martijn Coenen wrote:
> >> The ELF symbols are renamed to include the namespace with an asm label;
> >> for example,
+++ Martijn Coenen [24/07/18 09:56 +0200]:
I did find an issue with my approach:
On Mon, Jul 16, 2018 at 2:21 PM, Martijn Coenen wrote:
The ELF symbols are renamed to include the namespace with an asm label;
for example, symbol 'usb_stor_suspend' in namespace USB_STORAGE becomes
On Mon, 2018-07-23 at 08:37 -0600, Keith Busch wrote:
> diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
> index 8932ae81a15a..2715cdaa669c 100644
> --- a/drivers/scsi/scsi_error.c
> +++ b/drivers/scsi/scsi_error.c
> @@ -296,6 +296,20 @@ enum blk_eh_timer_return
On Wed, Jul 25, 2018 at 12:42 PM, Sreekanth Reddy
wrote:
> Swap the I/O memory read value back to cpu endianness before storing it
> in a data structures which are defined in the MPI headers where
> u8 components are not defined in the endianness order.
>
> In this area from day one mpt3sas
Any update on this patch!.
Thanks,
Sreekanth
On Fri, Jul 20, 2018 at 5:56 PM, Sreekanth Reddy
wrote:
> In mpt3sas_base_clear_st() function smid value is reseted in wrong line,
> i.e. driver should reset smid value to zero after decrementing chain_offset
> counter in chain_lookup table but in
Hello Dear.
My Name is Mrs. Bella Yostin Mohammad, I got your contact from a
business directory search and I decided to contact you directly. well
am originally from South Africa, but based in London, i am searching
for a reliable and honest and understanding person to go into
partnership in
en resarting the gluster-blockd, it will start the tcmu-runner and
gluster-block-target first.
And it is possible that the targetcli clear operation is stuck somewhere
then the runner is restarted.
If you re killing it at various times, how do you know you are not
killing it during a enab
801 - 900 of 39577 matches
Mail list logo
