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:
http:
On Thu, Oct 01, 2015 at 11:40:23AM +, Junichi Nomura wrote:
> 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
This patch looks fine to me:
Acked-by: Christoph Hellwig
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
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 a
On Thu, Oct 01, 2015 at 04:38:45AM +, Junichi Nomura wrote:
> But another workload using dm-multipath still caues the same crash.
> I think a patch like the following is needed.
> What do you think?
Thanks Junichi,
I suspected that we should defer the release until we tear down
the sdev inste
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 original post, I can't repro
On 10/01/15 00:18, Christoph Hellwig wrote:
> On Wed, Sep 30, 2015 at 12:35:50AM +, 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 086b91d052eb ("scsi_dh: inte
On Wed, Sep 30, 2015 at 12:35:50AM +, 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 086b91d052eb ("scsi_dh: integrate into the core SCSI code")
> moved the call
On 09/30/2015 12:35 PM, Boaz Harrosh wrote:
> On 09/30/2015 12:28 PM, Hannes Reinecke wrote:
> <>
>> Pushing things into the background is typically not the best of
>> ideas; actually I've been running into issues with udev not being
>> complete by the time the next round is started. So more often
On 09/30/2015 12:28 PM, Hannes Reinecke wrote:
<>
> Pushing things into the background is typically not the best of
> ideas; actually I've been running into issues with udev not being
> complete by the time the next round is started. So more often than
> not I would be greeted with messages:
>
> '
On 09/30/2015 02:35 AM, 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 086b91d052eb ("scsi_dh: integrate into the core SCSI code")
> moved the call of scsi_dh->detach
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 (scsi_
12 matches
Mail list logo