Re: [PATCH-v1 11/22] Fix driver unload/reload operation.

On 04/20/17 16:37, Johannes Thumshirn wrote: > On Wed, Apr 19, 2017 at 09:46:30PM -0700, jsmart2...@gmail.com wrote: >> From: James Smart <jsmart2...@gmail.com> >> >> There are couple of different load/unload issues fixed with this patch. >> One of the issu

Re: [REGRESSION] v4.11-rc3: lpfc: panic during module removal / shutdown

On 04/04/17 06:53, Mauricio Faria de Oliveira wrote: > Hi Junichi, > > On 03/28/2017 11:29 PM, Junichi Nomura wrote: >> Since commit 895427bd012c ("scsi: lpfc: NVME Initiator: Base modifications"), >> "rmmod lpfc" starting to cause panic or c

Re: [REGRESSION] v4.11-rc3: lpfc: panic during module removal / shutdown

On 03/29/17 20:17, Johannes Thumshirn wrote: > On Wed, Mar 29, 2017 at 02:29:45AM +0000, Junichi Nomura wrote: >> The double-free occurs as followings: >> - During initialization, lpfc_create_wq_cq() binds cq and wq to >> the same ring in the way that both cq->p

[REGRESSION] v4.11-rc3: lpfc: panic during module removal / shutdown

Since commit 895427bd012c ("scsi: lpfc: NVME Initiator: Base modifications"), "rmmod lpfc" starting to cause panic or corruption due to double free. The double-free occurs as followings: - During initialization, lpfc_create_wq_cq() binds cq and wq to the same ring in the way that both

Re: [PATCH 05/16] dm: always defer request allocation to the owner of the request_queue

On 01/25/17 01:39, Mike Snitzer wrote: > On Tue, Jan 24 2017 at 9:20am -0500, Christoph Hellwig wrote: >> On Tue, Jan 24, 2017 at 05:05:39AM -0500, Mike Snitzer wrote: >>> possible and is welcomed cleanup. The only concern I have is that using >>> get_request() for the old

Re: why is blk-mq requeue foricbly kicking stopped queues? [was: Re: dm-multipath test scripts]

On 02/23/16 00:09, Mike Snitzer wrote: > I should note that I applied this patch for 4.6: > https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-4.6=7db905b3d4294e5db4c2938fb7d0e5ba4bd798d6 > > (but it was purely a fallout of code-review, and looking at the nvme's

Re: dm-multipath test scripts

On 02/20/16 15:12, Mike Snitzer wrote: > On Fri, Feb 19 2016 at 2:42pm -0500, Mike Snitzer wrote: >> Have you been running with blk-mq? >> Either by setting CONFIG_DM_MQ_DEFAULT or: >> echo Y > /sys/module/dm_mod/parameters/use_blk_mq >> >> I'm seeing test_02_sdev_delete fail

Re: dm-multipath test scripts

On 02/19/16 09:33, Nomura Junichi wrote: > On 02/19/16 02:17, Mike Snitzer wrote: >> What is the last kernel version that your scripts have worked on? > > v4.4 worked fine. I'll check with v4.5-rc4 when I get a machine. v4.5-rc4 works fine, too. So if all tests fail for you, it might be due to

Re: dm-multipath test scripts

Hi Mike, On 02/19/16 02:17, Mike Snitzer wrote: > But unfortunately I cannot get either the scsidebug or tcmloop mode to > run against v4.5-rc4 > > For tcmloop, targetcli fails with: > "Could not create ISCSIFabricModule in configFS." Hmm, it sounds like there's unnecessary dependency in

Re: [PATCH for v4.3-rc] scsi_dh: fix use-after-free when removing scsi device

On 10/06/15 13:32, Junichi Nomura wrote: > The commit 1bab0de0274f ("dm-mpath, scsi_dh: don't let dm detach device > handlers") removed reference counting of attached scsi device handler. > As a result, handler data is freed immediately via scsi_dh->detach() > in the cont

Re: dm-multipath test scripts

On 10/07/15 16:31, Johannes Thumshirn wrote: > On Wed, 2015-10-07 at 05:39 +0000, Junichi Nomura wrote: >> This is a set of scripts for kernel-side dm-multipath testing. >> Current >> set of scripts are stress testing of extreme situation and its >> coverage >>

Re: [REGRESSION v4.3] scsi_dh: use-after-free when removing scsi device

On 10/04/15 16:42, Christoph Hellwig wrote: > Any chance you could share your various scripts in some way to that > people doing multipath changes can run them to verify those changes? Hi Christoph, I've refined some pieces of test scripts which could be useful for people and posted here:

dm-multipath test scripts

This is a set of scripts for kernel-side dm-multipath testing. Current set of scripts are stress testing of extreme situation and its coverage is limited. But recently found dm-mpath regressions should be detectable with this. I hope this helps people working on dm-multipath related code as a

[PATCH for v4.3-rc] scsi_dh: fix use-after-free when removing scsi device

The commit 1bab0de0274f ("dm-mpath, scsi_dh: don't let dm detach device handlers") removed reference counting of attached scsi device handler. As a result, handler data is freed immediately via scsi_dh->detach() in the context of scsi_remove_device() where activation request can be still in

Re: [REGRESSION v4.3] scsi_dh: use-after-free when removing scsi device

On 10/01/15 14:21, Christoph Hellwig wrote: > Any chance you could share all your multipath tests in a git repository > somewhere? It seems like you're the only one actually having a good > set of reproducable but minimalistic tests. Hmm, sorry I don't have a public git repository... I'm using

Re: [REGRESSION v4.3] scsi_dh: use-after-free when removing scsi device

On 10/01/15 00:18, Christoph Hellwig wrote: > On Wed, Sep 30, 2015 at 12:35:50AM +0000, Junichi Nomura wrote: >> With v4.3-rc3, stress testing of SCSI device addition/removal quickly >> trigger random crash in memory allocator (e.g. __kmalloc). I found that >> a commit 0

Re: [REGRESSION v4.3] scsi_dh: use-after-free when removing scsi device

On 10/01/15 09:56, Junichi Nomura wrote: > With 4.2 kernel, scsi_dh->detach() was not called until the last > reference has gone. With 4.3-rc3, scsi_dh->detach() is directly called > from the context of scsi_remove_device(). That's the point. For my test script in the origina

[REGRESSION v4.3] scsi_dh: use-after-free when removing scsi device

With v4.3-rc3, stress testing of SCSI device addition/removal quickly trigger random crash in memory allocator (e.g. __kmalloc). I found that a commit 086b91d052eb ("scsi_dh: integrate into the core SCSI code") moved the call of scsi_dh->detach() to very early part of sdev tear down process

Re: [PATCH] x86: Fix gfp flags for coherent DMA memory allocation

On 09/14/15 16:38, Junichi Nomura wrote: > Commit 6894258eda2f reversed the order of gfp_flags adjustment in > dma_alloc_attrs() for x86 [arch/x86/kernel/pci-dma.c] > As a result, relevant flags set by dma_alloc_coherent_gfp_flags() > is just discarded and causes coherent DMA memor