On Thu, Jan 08, 2015 at 12:35:02PM -0800, James Bottomley wrote:
> What's the transition plan for userspace? If you look at glibc
> currently, it supplies both scsi.h and scsi_ioctl.h. If we're
> persuading the glibc folks to go with our versions from uapi, I think
> removing a file which is an e
On Thu, Jan 08, 2015 at 11:47:58AM -0800, Andy Grover wrote:
> A great many SCSI codes and ioctl values can be made available to userspace
> in a uapi header, while the kernel-only definitions stay in scsi/scsi.h.
>
> scsi/scsi.h also includes uapi/scsi/scsi.h so kernel code need not update
> incl
This is a reminder that the deadline for the LSF/MM 2015 CFP is approaching
-- see http://lwn.net/Articles/623534/ for the original announcement. The
deadline for ATTEND and TOPIC requests is January 16th so now is the time
to get them sent in if you're interested in attending.
Thank you on behalf
On 1/9/2015 1:26 AM, Mike Christie wrote:
I am not sure if we want this to be a deciding factor. I think the
session wide lock is something that can be removed in the main IO paths.
A lot of what it is used for now is cmd/task related handling like list
accesses. When we have the scsi layer all
On 1/8/2015 4:11 PM, Bart Van Assche wrote:
On 01/08/15 14:45, Sagi Grimberg wrote:
Actually I started with that approach, but the independent connections
under a single session (I-T-Nexus) violates the command ordering
requirement. Plus, such a solution is specific to iSER...
Hello Sagi,
Whi
Any chance to get a review / ack for this one?
On Wed, Jan 07, 2015 at 03:20:53PM +0100, Christoph Hellwig wrote:
> The blk-mq ->queue_rq method is always called from process context,
> but might have preemption disabled. This means we still always
> have to use GFP_ATOMIC for memory allocations,
On 01/09/15 12:39, Sagi Grimberg wrote:
> On 1/8/2015 4:11 PM, Bart Van Assche wrote:
>> On 01/08/15 14:45, Sagi Grimberg wrote:
>>> Actually I started with that approach, but the independent connections
>>> under a single session (I-T-Nexus) violates the command ordering
>>> requirement. Plus, suc
On Thu, 2015-01-08 at 14:49 -0800, Nicholas A. Bellinger wrote:
> On Thu, 2015-01-08 at 09:37 -0500, Martin K. Petersen wrote:
> > > "nab" == Nicholas A Bellinger writes:
> >
> > nab> IIRC, most modern hardware is reporting a large enough value for
> > nab> queue_max_hw_sectors() to support 8
On 01/07/15 15:20, Christoph Hellwig wrote:
> The blk-mq ->queue_rq method is always called from process context,
> but might have preemption disabled. This means we still always
> have to use GFP_ATOMIC for memory allocations, and thus need to
> revert part of commit 3c356bde1 ("scsi: stop passin
On Fri, 2015-01-09 at 11:14 +0100, Christoph Hellwig wrote:
> On Thu, Jan 08, 2015 at 11:47:58AM -0800, Andy Grover wrote:
> > A great many SCSI codes and ioctl values can be made available to userspace
> > in a uapi header, while the kernel-only definitions stay in scsi/scsi.h.
> >
> > scsi/scsi.
On Fri, Jan 09, 2015 at 07:27:46AM -0800, James Bottomley wrote:
> Actually, they are exported. If you look at what glibc supplies, it has
> it's own copies of scsi.h and scsi_ioctl.h. If we try to repace those
> with uapi, we have to make sure nothing breaks, so the opcodes have to
> be in scsi.
On 01/09/2015 04:51 AM, Christoph Hellwig wrote:
Any chance to get a review / ack for this one?
You can my reviewed-by, looks fine to me.
--
Jens Axboe
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo
On Fri, 2015-01-09 at 16:46 +0100, Christoph Hellwig wrote:
> On Fri, Jan 09, 2015 at 07:27:46AM -0800, James Bottomley wrote:
> > Actually, they are exported. If you look at what glibc supplies, it has
> > it's own copies of scsi.h and scsi_ioctl.h. If we try to repace those
> > with uapi, we ha
drivers/scsi/megaraid/megaraid_sas_base.c:1701:6: sparse: symbol
'megasas_complete_outstanding_ioctls' was not declared. Should it be static?
Signed-off-by: Fengguang Wu
---
megaraid_sas_base.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/megaraid/megaraid
This patch fixes sparse warning reported by kbuild.
Apply this on net-next since it depends on previous commit.
drivers/scsi/csiostor/csio_hw.c:259:17: sparse: cast to restricted __le32
drivers/scsi/csiostor/csio_hw.c:536:31: sparse: incorrect type in assignment
(different base types)
drivers/scsi
tree: git://git.infradead.org/users/hch/scsi-queue.git scsi-for-3.20
head: 0128d5cf8f85c93b3c70ff03299c2839f3e6d21e
commit: c8dd61eff2780c481fcf919c1572e16e397c714e [39/42] megaraid_sas: complete
outstanding IOCTLs before killing adapter
reproduce:
# apt-get install sparse
git checkout c8d
On Fri, Jan 09, 2015 at 07:50:38AM -0800, James Bottomley wrote:
> Right, that's why I'm dubious about this effort. uapi files either have
> to become the glibc headers or be exported in a way that allows
> inclusion into glibc headers for there to be any point.
uapi headers are not just for glib
I'd like to attend LSF -- I am responsible for maintaining the SCSI
subsystem at Red Hat, and in addition to resolving issues for customers
and partners, I've been participating in upstream development for the
past couple of years. I have an extensive background in SCSI and OS
development, includi
On Fri, 2015-01-09 at 17:01 +0100, Christoph Hellwig wrote:
> On Fri, Jan 09, 2015 at 07:50:38AM -0800, James Bottomley wrote:
> > Right, that's why I'm dubious about this effort. uapi files either have
> > to become the glibc headers or be exported in a way that allows
> > inclusion into glibc he
On Fri, Jan 09, 2015 at 08:33:00AM -0800, James Bottomley wrote:
> Yes, but they have to be delivered to users somehow. If you look at
> debian, they deliver the headers through the linux-dev-libc package
> which installs into the /usr/include directory.
linux-libc-dev despite the name is provide
Hello glibc people,
This concerns sysdeps/unix/sysv/linux/scsi/{scsi, scsi_ioctl, sg}.h
They define common SCSI values, as well as Linux's SCSI-related ioctls.
Apparently they were copied from the Linux kernel tree back in 1999, so
they're pretty stale.
I'm wondering if I should submit a pat
On Fri, 2015-01-09 at 18:11 +0100, Christoph Hellwig wrote:
> On Fri, Jan 09, 2015 at 08:33:00AM -0800, James Bottomley wrote:
> > Yes, but they have to be delivered to users somehow. If you look at
> > debian, they deliver the headers through the linux-dev-libc package
> > which installs into the
On Jan 8, 2015, at 11:03 PM, Nicholas A. Bellinger wrote:
> On Thu, 2015-01-08 at 15:22 -0800, James Bottomley wrote:
>> On Thu, 2015-01-08 at 14:57 -0800, Nicholas A. Bellinger wrote:
>>> On Thu, 2015-01-08 at 14:29 -0800, James Bottomley wrote:
On Thu, 2015-01-08 at 14:16 -0800, Nicholas
On 01/09/2015 07:00 PM, Michael Christie wrote:
>
> On Jan 8, 2015, at 11:03 PM, Nicholas A. Bellinger
> wrote:
>
>> On Thu, 2015-01-08 at 15:22 -0800, James Bottomley wrote:
>>> On Thu, 2015-01-08 at 14:57 -0800, Nicholas A. Bellinger wrote:
On Thu, 2015-01-08 at 14:29 -0800, James Bottom
On Fri, 2015-01-09 at 19:28 +0100, Hannes Reinecke wrote:
[...]
> > I think you are assuming we are leaving the iscsi code as it is today.
> >
> > For the non-MCS mq session per CPU design, we would be allocating and
> > binding the session and its resources to specific CPUs. They would only
> > b
On Wednesday 07 January 2015 15:34:32 Christoph Hellwig wrote:
> On Tue, Jan 06, 2015 at 11:27:28PM +0100, Ondrej Zary wrote:
> > > note that the last two even drive the same hardware. There is
> > > significant cruft in all these, so dropping them would help
> > > further maintainance of the SCSI
Just one fix: a qlogic busy wait regression.
The patch is available here:
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes
The short changelog is:
Bruno Prémont (1):
qla2xxx: fix busy wait regression
And the diffstat:
drivers/scsi/qla2xxx/qla_os.c | 4 +++-
1 file
On 01/09/2015 12:28 PM, Hannes Reinecke wrote:
> On 01/09/2015 07:00 PM, Michael Christie wrote:
>>
>> On Jan 8, 2015, at 11:03 PM, Nicholas A. Bellinger
>> wrote:
>>
>>> On Thu, 2015-01-08 at 15:22 -0800, James Bottomley wrote:
On Thu, 2015-01-08 at 14:57 -0800, Nicholas A. Bellinger wrote:
> "nab" == Nicholas A Bellinger writes:
nab> The concern is when older hardware drivers are reporting say
nab> queue_max_hw_sectors=128 with initiators are not actively honoring
nab> block limits EVPD MAXIMUM TRANSFER LENGTH, that would result in
nab> I/Os over 64K generating exception status
> "Sreekanth" == Sreekanth Reddy writes:
Sreekanth> 1. Extended the upper boundary restriction for the module
Sreekanth> parameter max_sgl_entries. Earlier, the max_sgl_entries was
Sreekanth> capped at the SCSI_MAX_SG_SEGMENTS kernel definition. With
Sreekanth> this change, the user would b
> "Sreekanth" == Sreekanth Reddy writes:
Sreekanth> Change_set: 1. Added affinity_hint varable of type
Sreekanth> cpumask_var_t in adapter_reply_queue structure. And allocated
Sreekanth> a memory for this varable by calling alloc_cpumask_var.
Sreekanth> 2. Call the API irq_set_affinity_hint f
On Fri, 2015-01-09 at 15:43 -0500, Martin K. Petersen wrote:
> > "nab" == Nicholas A Bellinger writes:
>
> nab> The concern is when older hardware drivers are reporting say
> nab> queue_max_hw_sectors=128 with initiators are not actively honoring
> nab> block limits EVPD MAXIMUM TRANSFER LENG
From: Nicholas Bellinger
This patch drops the arbitrary maximum I/O size limit in sbc_parse_cdb(),
which currently for fabric_max_sectors is hardcoded to 8192 (4 MB for 512
byte sector devices), and for hw_max_sectors is a backend driver dependent
value.
This limit is problematic because Linux i
From: Nicholas Bellinger
Now that fabric_max_sectors is no longer used to enforce the maximum
I/O size, go ahead and drop it's left-over usage in target-core and
associated backend drivers.
Cc: Christoph Hellwig
Cc: Martin K. Petersen
Cc: Roland Dreier
Signed-off-by: Nicholas Bellinger
---
34 matches
Mail list logo
