On 18.07.2014 22:16, poma wrote:
On 18.07.2014 22:07, James Bottomley wrote:
On Fri, 2014-07-18 at 22:01 +0200, poma wrote:
On 18.07.2014 16:17, Christoph Hellwig wrote:
On Fri, Jul 18, 2014 at 05:21:04PM +0400, Vladimir Davydov wrote:
Slab warns, because the name of the cache being created c
On 18.07.2014 22:07, James Bottomley wrote:
On Fri, 2014-07-18 at 22:01 +0200, poma wrote:
On 18.07.2014 16:17, Christoph Hellwig wrote:
On Fri, Jul 18, 2014 at 05:21:04PM +0400, Vladimir Davydov wrote:
Slab warns, because the name of the cache being created contains spaces.
The "bad" cache is
On Fri, 2014-07-18 at 22:01 +0200, poma wrote:
> On 18.07.2014 16:17, Christoph Hellwig wrote:
> > On Fri, Jul 18, 2014 at 05:21:04PM +0400, Vladimir Davydov wrote:
> >> Slab warns, because the name of the cache being created contains spaces.
> >> The "bad" cache is created by scsi_get_host_cmd_poo
On 18.07.2014 16:17, Christoph Hellwig wrote:
On Fri, Jul 18, 2014 at 05:21:04PM +0400, Vladimir Davydov wrote:
Slab warns, because the name of the cache being created contains spaces.
The "bad" cache is created by scsi_get_host_cmd_pool. Its name
(pool->cmd_name) is initialized by scsi_alloc_ho
On Fri, 2014-07-18 at 11:17 -0700, Greg KH wrote:
> On Fri, Jul 18, 2014 at 09:54:32AM -0700, James Bottomley wrote:
> > On Fri, 2014-07-18 at 09:43 -0700, Greg KH wrote:
> > > On Fri, Jul 18, 2014 at 12:22:13PM -0400, John W. Linville wrote:
> > > > On Fri, Jul 18, 2014 at 05:26:47PM +0200, Benoit
On Fri, Jul 18, 2014 at 09:54:32AM -0700, James Bottomley wrote:
> On Fri, 2014-07-18 at 09:43 -0700, Greg KH wrote:
> > On Fri, Jul 18, 2014 at 12:22:13PM -0400, John W. Linville wrote:
> > > On Fri, Jul 18, 2014 at 05:26:47PM +0200, Benoit Taine wrote:
> > > > We should prefer `const struct pci_d
On 14-07-18 07:41 AM, James Bottomley wrote:
On Fri, 2014-07-18 at 17:17 +, Elliott, Robert (Server Storage)
wrote:
From: James Bottomley [mailto:jbottom...@parallels.com]
On Fri, 2014-07-18 at 00:51 +, Elliott, Robert (Server Storage)
wrote:
...
Also, in both sd_setup_flush_cmnd
On Fri, 2014-07-18 at 09:43 -0700, Greg KH wrote:
> On Fri, Jul 18, 2014 at 12:22:13PM -0400, John W. Linville wrote:
> > On Fri, Jul 18, 2014 at 05:26:47PM +0200, Benoit Taine wrote:
> > > We should prefer `const struct pci_device_id` over
> > > `DEFINE_PCI_DEVICE_TABLE` to meet kernel coding styl
On Fri, 2014-07-18 at 17:17 +, Elliott, Robert (Server Storage)
wrote:
>
>
> > From: James Bottomley [mailto:jbottom...@parallels.com]
> >
> > On Fri, 2014-07-18 at 00:51 +, Elliott, Robert (Server Storage)
> > wrote:
> ...
> > >
> > > Also, in both sd_setup_flush_cmnd and sd_sync_cache:
> From: James Bottomley [mailto:jbottom...@parallels.com]
>
> On Fri, 2014-07-18 at 00:51 +, Elliott, Robert (Server Storage)
> wrote:
...
> >
> > Also, in both sd_setup_flush_cmnd and sd_sync_cache:
> > cmd->cmnd[0] = SYNCHRONIZE_CACHE;
> > cmd->cmd_len = 10;
> >
> > SYNCHRONIZE
On Fri, Jul 18, 2014 at 10:12:38AM -0700, h...@infradead.org wrote:
> This is what I plan to put in after it passes basic testing:
And that one was on top of my previous version. One that applies
against core-for-3.17 below:
---
>From 8a79783e5f72ec034a724e16c1f46604bd97bf68 Mon Sep 17 00:00:00
This is what I plan to put in after it passes basic testing:
---
>From bb617c9465b839d70ecbbc69002a20ccf5f935bd Mon Sep 17 00:00:00 2001
From: "K. Y. Srinivasan"
Date: Fri, 18 Jul 2014 19:12:58 +0200
Subject: sd: fix a bug in deriving the FLUSH_TIMEOUT from the basic I/O
timeout
Commit ID: 7e66
> -Original Message-
> From: James Bottomley [mailto:jbottom...@parallels.com]
> Sent: Friday, July 18, 2014 9:57 AM
> To: KY Srinivasan
> Cc: linux-ker...@vger.kernel.org; h...@infradead.org; a...@canonical.com;
> de...@linuxdriverproject.org; micha...@cs.wisc.edu; ax...@kernel.dk;
> lin
On Fri, 2014-07-18 at 10:00 -0700, Christoph Hellwig wrote:
> On Wed, Jun 04, 2014 at 09:33:43AM -0700, K. Y. Srinivasan wrote:
> > Commit ID: 7e660100d85af860e7ad763202fff717adcdaacd added code to derive the
> > FLUSH_TIMEOUT from the basic I/O timeout. However, this patch did not use
> > the
> >
On Wed, Jun 04, 2014 at 09:33:43AM -0700, K. Y. Srinivasan wrote:
> Commit ID: 7e660100d85af860e7ad763202fff717adcdaacd added code to derive the
> FLUSH_TIMEOUT from the basic I/O timeout. However, this patch did not use the
> basic I/O timeout of the device. Fix this bug.
>
> Signed-off-by: K. Y.
On Fri, Jul 18, 2014 at 04:57:13PM +, James Bottomley wrote:
> Actually, no you didn't. The difference is in the derivation of the
> timeout. Christoph's patch is absolute in terms of SD_TIMEOUT; yours is
> relative to the queue timeout setting ... I thought there was a reason
> for preferrin
On Fri, 2014-07-18 at 16:44 +, KY Srinivasan wrote:
>
> > -Original Message-
> > From: Christoph Hellwig (h...@infradead.org) [mailto:h...@infradead.org]
> > Sent: Friday, July 18, 2014 8:11 AM
> > To: KY Srinivasan
> > Cc: Jens Axboe; James Bottomley; micha...@cs.wisc.edu; Christoph H
On Fri, 2014-07-18 at 09:43 -0700, Greg KH wrote:
> On Fri, Jul 18, 2014 at 12:22:13PM -0400, John W. Linville wrote:
> > On Fri, Jul 18, 2014 at 05:26:47PM +0200, Benoit Taine wrote:
> > > We should prefer `const struct pci_device_id` over
> > > `DEFINE_PCI_DEVICE_TABLE` to meet kernel coding styl
On Fri, Jul 18, 2014 at 12:22:13PM -0400, John W. Linville wrote:
> On Fri, Jul 18, 2014 at 05:26:47PM +0200, Benoit Taine wrote:
> > We should prefer `const struct pci_device_id` over
> > `DEFINE_PCI_DEVICE_TABLE` to meet kernel coding style guidelines.
> > This issue was reported by checkpatch.
>
> -Original Message-
> From: Christoph Hellwig (h...@infradead.org) [mailto:h...@infradead.org]
> Sent: Friday, July 18, 2014 8:11 AM
> To: KY Srinivasan
> Cc: Jens Axboe; James Bottomley; micha...@cs.wisc.edu; Christoph Hellwig
> (h...@infradead.org); linux-scsi@vger.kernel.org;
> gre...
On Fri, Jul 18, 2014 at 05:26:47PM +0200, Benoit Taine wrote:
> We should prefer `const struct pci_device_id` over
> `DEFINE_PCI_DEVICE_TABLE` to meet kernel coding style guidelines.
> This issue was reported by checkpatch.
Honestly, I prefer the macro -- it stands-out more. Maybe the style
guide
On Fri, 2014-07-18 at 17:26 +0200, Benoit Taine wrote:
> We should prefer `const struct pci_device_id` over
> `DEFINE_PCI_DEVICE_TABLE` to meet kernel coding style guidelines.
> This issue was reported by checkpatch.
What kernel coding style? checkpatch isn't the arbiter of style, if
that's the o
We should prefer `struct pci_device_id` over `DEFINE_PCI_DEVICE_TABLE` to meet
kernel coding style guidelines. This issue was reported by checkpatch.
Signed-off-by: Benoit Taine
---
Tested by compilation without errors.
drivers/scsi/BusLogic.c |2 +-
1 file changed, 1 insertion(+), 1 delet
On Fri, 2014-07-18 at 00:51 +, Elliott, Robert (Server Storage)
wrote:
> In sd_sync_cache:
> rq->timeout *= SD_FLUSH_TIMEOUT_MULTIPLIER;
>
> Regardless of the baseline for the multiplication, a magic
> number of 2 is too arbitrary. That might work for an
> individual drive, but could b
We should prefer `const struct pci_device_id` over
`DEFINE_PCI_DEVICE_TABLE` to meet kernel coding style guidelines.
This issue was reported by checkpatch.
A simplified version of the semantic patch that makes this change is as
follows (http://coccinelle.lip6.fr/):
//
@@
identifier i;
declarer
We currently set the field in common code based on the device type,
but then only use it in the cdrom driver which also overrides the
value previously set in the generic code.
Just leave this entirely to the CDROM driver to make everyones life
simpler.
Signed-off-by: Christoph Hellwig
---
drive
Make sure we have a symbolic name for the ZBC type available,
so that e.g. patch for a SATA to translate ZAC commands can
make use of it.
Signed-off-by: Christoph Hellwig
---
include/scsi/scsi.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/scsi/scsi.h b/include/scsi/scsi.h
index 9
Add two new device types, most importantly the zoned block device
one.
Split from an earlier patch by Hannes Reinecke.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/scsi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index 013709f..33318f5
Two trivial patches extracted from Hannes' ZBC series, and one cleanup
in response to my review of it.
--
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 Fri, Jul 18, 2014 at 12:51:06AM +, Elliott, Robert (Server Storage)
wrote:
> SYNCHRONIZE CACHE (16) should be favored over SYNCHRONIZE
> CACHE (10) unless SYNCHRONIZE CACHE (10) is not supported.
I gues you mean (16) for the last occurance? What's the benefit of
using SYNCHRONIZE CACHE (
On Thu, Jul 17, 2014 at 11:53:33PM +, KY Srinivasan wrote:
> I still see this problem. There was talk of fixing it elsewhere.
Well, what we have right not is entirely broken, given that the
block layer doesn't initialize ->timeout on TYPE_FS requeuests.
We either need to revert that initial c
On Fri, Jul 18, 2014 at 11:00 PM, Paolo Bonzini wrote:
> Il 18/07/2014 16:57, Ming Lei ha scritto:
>> - if (sc->sense_buffer) {
>> + if (resp->sense_len) {
>
> In the (unlikely) case that sc->sense_buffer == NULL, you'd pass a NULL
> to memcpy.
Every valid scsi_cmnd should have non NULL s
> -Original Message-
> From: Christoph Hellwig [mailto:h...@infradead.org]
> Sent: Friday, July 18, 2014 8:04 AM
> To: Martin K. Petersen
> Cc: linux-scsi@vger.kernel.org; KY Srinivasan
> Subject: Re: [PATCH] SCSI: Add a blacklist flag which enables VPD page
> inquiries
>
> On Tue, Jul 1
On Tue, Jul 15, 2014 at 12:49:17PM -0400, Martin K. Petersen wrote:
>
> Despite supporting modern SCSI features some storage devices continue to
> claim conformance to an older version of the SPC spec. This is done for
> compatibility with legacy operating systems.
>
> Linux by default will n
Il 18/07/2014 16:57, Ming Lei ha scritto:
> - if (sc->sense_buffer) {
> + if (resp->sense_len) {
In the (unlikely) case that sc->sense_buffer == NULL, you'd pass a NULL
to memcpy.
If you want, you can change this if to
if (sc->sense_buffer && resp->sense_len)
but frankly it seem
The 'sense_buffer' of 'struct scsi_cmnd' is always true, but
resp->sense_len is only set if there is sense available.
Signed-off-by: Ming Lei
---
drivers/scsi/virtio_scsi.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virti
On Fri, 18 Jul 2014, Tomas Henzl wrote:
> > + if (src_sector + nr_sects < src_sector ||
> > + dst_sector + nr_sects < dst_sector)
> > + return -EINVAL;
>
> Hi Mikulas,
> this^ is meant as an overflow test or what is the reason?
> Thanks, Tomas
Yes. It is a test for overflow.
On Fri, Jul 18, 2014 at 05:21:04PM +0400, Vladimir Davydov wrote:
> Slab warns, because the name of the cache being created contains spaces.
> The "bad" cache is created by scsi_get_host_cmd_pool. Its name
> (pool->cmd_name) is initialized by scsi_alloc_host_cmd_pool as follows:
>
> pool->cm
Slab warns, because the name of the cache being created contains spaces.
The "bad" cache is created by scsi_get_host_cmd_pool. Its name
(pool->cmd_name) is initialized by scsi_alloc_host_cmd_pool as follows:
pool->cmd_name = kasprintf(GFP_KERNEL, "%s_cmd", hostt->name);
So, if hostt->name
On 07/15/2014 09:34 PM, Mikulas Patocka wrote:
> This is Martin Petersen's xcopy patch
> (https://git.kernel.org/cgit/linux/kernel/git/mkp/linux.git/commit/?h=xcopy&id=0bdeed274e16b3038a851552188512071974eea8)
> with some bug fixes, ported to the current kernel.
>
> This patch makes it possible to
Peter:
We will check with Falcon MR controller and will get back to you. Can you
quickly check using stable kernel instead of upstream. (Just to check if
it is regression>) ?
~ Kashyap
> -Original Message-
> From: linux-scsi-ow...@vger.kernel.org [mailto:linux-scsi-
> ow...@vger.kernel.o
This is a development of "percpu_ida" library. The major
differrences between "percpu_ida" and "percpu_tags" are:
* The global freelist has gone. As result, CPUs do not compete
for the global lock.
* Long-running operatons (scanning thru a cpumask) are executed
with local interrupts enabled;
Hello Gentleman,
This is a development of "percpu_ida" library. I named it
"percpu_tags" to simplify review, since most of "percpu_ida"
code has gone and a diff would not be informative.
While the concept of per-cpu arrays is is preserved, the
implementation is heavily reworked. The main objectiv
All users of "percpu_ida" are blindly converted to
"percpu_tags" users. No testing has been conducted.
Signed-off-by: Alexander Gordeev
Cc: linux-scsi@vger.kernel.org
Cc: qla2xxx-upstr...@qlogic.com
Cc: Nicholas Bellinger
Cc: Kent Overstreet
Cc: "Michael S. Tsirkin"
---
drivers/scsi/qla2xxx/q
Make sure we only have the logic for requeing commands in one place.
Signed-off-by: Christoph Hellwig
Reviewed-by: Hannes Reinecke
Reviewed-by: Webb Scales
Acked-by: Jens Axboe
Tested-by: Bart Van Assche
Tested-by: Robert Elliott
---
drivers/scsi/scsi.c | 35
The blk-mq code path will set this to a different function, so make the
code simpler by setting it up in a legacy-request specific place.
Signed-off-by: Christoph Hellwig
Reviewed-by: Hannes Reinecke
Reviewed-by: Webb Scales
Acked-by: Jens Axboe
Tested-by: Bart Van Assche
Tested-by: Robert El
Avoid taking the queue_lock to check the per-device queue limit. Instead
we do an atomic_inc_return early on to grab our slot in the queue,
and if necessary decrement it after finishing all checks.
Unlike the host and target busy counters this doesn't allow us to avoid the
queue_lock in the reque
Prepare for not taking a host-wide lock in the dispatch path by pushing
the lock down into the places that actually need it. Note that this
patch is just a preparation step, as it will actually increase lock
roundtrips and thus decrease performance on its own.
Signed-off-by: Christoph Hellwig
Re
Avoid taking the host-wide host_lock to check the per-host queue limit.
Instead we do an atomic_inc_return early on to grab our slot in the queue,
and if nessecary decrement it after finishing all checks.
Signed-off-by: Christoph Hellwig
Reviewed-by: Hannes Reinecke
Reviewed-by: Webb Scales
Ack
Avoid taking the host-wide host_lock to check the per-target queue limit.
Instead we do an atomic_inc_return early on to grab our slot in the queue,
and if nessecary decrement it after finishing all checks.
Signed-off-by: Christoph Hellwig
Reviewed-by: Hannes Reinecke
Reviewed-by: Webb Scales
A
Seems like these counters are missing any sort of synchronization for
updates, as a over 10 year old comment from me noted. Fix this by
using atomic counters, and while we're at it also make sure they are
in the same cacheline as the _busy counters and not needlessly stored
to in every I/O complet
Factor out command setup code that will be shared with the blk-mq code path.
Signed-off-by: Christoph Hellwig
---
drivers/scsi/scsi_lib.c | 40 ++--
1 file changed, 22 insertions(+), 18 deletions(-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib
Replace the calls to the various blk_end_request variants with opencode
equivalents. Blk-mq is using a model that gives the driver control
between the bio updates and the actual completion, and making the old
code follow that same model allows us to keep the code more similar for
both paths.
Sign
Current the midlayer fakes up a struct request for the explicit reset
ioctls, and those don't have a tag allocated to them. The fnic driver pokes
into midlayer structures to paper over this design issue, but that won't
work for the blk-mq case.
Either someone who can actually test the hardware wi
This patch adds support for an alternate I/O path in the scsi midlayer
which uses the blk-mq infrastructure instead of the legacy request code.
Use of blk-mq is fully transparent to drivers, although for now a host
template field is provided to opt out of blk-mq usage in case any unforseen
incompa
Blk-mq drivers usually preallocate their S/G list as part of the request,
but if we want to support the very large S/G lists currently supported by
the SCSI code that would tie up a lot of memory in the preallocated request
pool. Add support to the scatterlist code so that it can initialize a
S/G
This saves us an atomic operation for each I/O submission and completion
for the usual case where the driver doesn't set a per-target can_queue
value. Only a few iscsi hardware offload drivers set the per-target
can_queue value at the moment.
Signed-off-by: Christoph Hellwig
Reviewed-by: Webb Sc
Factor out a helper to set the _blocked values, which we'll reuse for the
blk-mq code path.
Signed-off-by: Christoph Hellwig
Reviewed-by: Hannes Reinecke
Reviewed-by: Webb Scales
Acked-by: Jens Axboe
Tested-by: Bart Van Assche
Tested-by: Robert Elliott
---
drivers/scsi/scsi_lib.c | 44 +
At this point the code is ready for merging and use by developers and early
adopters. Except for the newly added first patch all have been thru multiple
review cycles and I would like to merge the series early next week assuming
I can get reviews for this. Please scream loud if you see any reason
I've pushed out new version of the for-3.17 core and drivers trees:
git://git.infradead.org/users/hch/scsi-queue.git core-for-3.17
git://git.infradead.org/users/hch/scsi-queue.git drivers-for-3.17
In the core tree the biggest update is the merge of the I/O path
cleanups, in addition various i
On Thu, Jul 17, 2014 at 02:39:30PM -0500, Robert Elliott wrote:
> In _scsih_probe, propagate the return value from scsi_add_host.
> In mpt3sas, avoid calling list_del twice if that returns an
> error, which causes list_del corruption warnings if an error
> is returned.
>
> Tested with blk-mq and s
On Thu, Jul 17, 2014 at 02:39:21PM -0500, Robert Elliott wrote:
> Two of the blk-mq based drivers do not pass back the return value
> from blk_mq_alloc_tag_set, instead just returning -ENOMEM.
>
> blk_mq_alloc_tag_set returns -EINVAL if the number of queues or
> queue depth is bad. -ENOMEM implie
On Thu, Jul 17, 2014 at 02:39:09PM -0500, Robert Elliott wrote:
> In blk-mq.c blk_mq_alloc_tag_set, if:
> set->tags = kmalloc_node()
> succeeds, but one of the blk_mq_init_rq_map() calls fails,
> goto out_unwind;
> needs to free set->tags so the caller is not obligated
> to do so. None
63 matches
Mail list logo
