Re: [PATCH] bsg referencing bus driver module

On Fri, 2018-04-20 at 16:44 -0600, Anatoliy Glagolev wrote: >   > > This patch isn't applyable because your mailer has changed all the > > tabs to spaces. > > > > I also think there's no need to do it this way.  I think what we > > need is for fc_bsg_remove() to wait until the bsg queue is > >

Re: [PATCH] bsg referencing bus driver module

On Thu, 2018-04-19 at 15:10 -0700, Anatoliy Glagolev wrote: > Updated: rebased on recent Linux, cc-ed maintainers per instructions > in MAINTAINERS file > > From df939b80d02bf37b21efaaef8ede86cfd39b0cb8 Mon Sep 17 00:00:00 > 2001 > From: Anatoliy Glagolev > Date: Thu,

Re: usercopy whitelist woe in scsi_sense_cache

On Mon, 2018-04-16 at 20:12 -0700, Kees Cook wrote: > I still haven't figured this out, though... any have a moment to look > at this? Just to let you know you're not alone ... but I can't make any sense of this either. The bfdq is the elevator_data, which is initialised when the scheduler is

Re: [PATCH] scsi: resolve COMMAND_SIZE at compile time

On Sat, 2018-03-10 at 14:29 +0100, Stephen Kitt wrote: > Hi Bart, > > On Fri, 9 Mar 2018 22:47:12 +, Bart Van Assche c.com> > wrote: > > > > On Fri, 2018-03-09 at 23:33 +0100, Stephen Kitt wrote: > > > > > > +/* > > > + * SCSI command sizes are as follows, in bytes, for

Re: [LSF/MM TOPIC] Two blk-mq related topics

On Mon, 2018-01-29 at 14:00 -0700, Jens Axboe wrote: > On 1/29/18 1:56 PM, James Bottomley wrote: > > > > On Mon, 2018-01-29 at 23:46 +0800, Ming Lei wrote: > > [...] > > > > > > 2. When to enable SCSI_MQ at default again? > > > > I'm not

Re: [LSF/MM TOPIC] Two blk-mq related topics

On Mon, 2018-01-29 at 23:46 +0800, Ming Lei wrote: [...] > 2. When to enable SCSI_MQ at default again? I'm not sure there's much to discuss ... I think the basic answer is as soon as Christoph wants to try it again. > SCSI_MQ is enabled on V3.17 firstly, but disabled at default. In > V4.13-rc1,

Re: [LSF/MM TOPIC] Springfield: smart and automated storage

On Sat, 2018-01-27 at 09:37 +0100, Jan Tulak wrote: > Springfield is a collection of projects unifying multiple levels of > the storage stack and providing a general API for automation, health > and status monitoring, as well as sane and easy configuration across > multiple levels of the storage

Re: [Lsf-pc] [LSF/MM TOPIC] A high-performance userspace block driver

On Tue, 2018-01-16 at 18:23 -0500, Theodore Ts'o wrote: > On Tue, Jan 16, 2018 at 06:52:40AM -0800, Matthew Wilcox wrote: > > > > > > I see the improvements that Facebook have been making to the nbd > > driver, and I think that's a wonderful thing.  Maybe the outcome of > > this topic is simply:

Re: [PATCH 1/2] scsi-mq: Only show the CDB if available

On Wed, 2017-12-06 at 00:38 +0800, Ming Lei wrote: > On Tue, Dec 05, 2017 at 04:22:33PM +, Bart Van Assche wrote: > > > > On Tue, 2017-12-05 at 13:00 +0800, Ming Lei wrote: > > > > > > No, do not mix two different things in one patch, especially the > > > fix part need to be backported to

Re: [PATCH V4] scsi_debugfs: fix crash in scsi_show_rq()

On Wed, 2017-11-15 at 18:09 +0800, Ming Lei wrote: > On Tue, Nov 14, 2017 at 10:14:52AM -0800, James Bottomley wrote: > > > > On Tue, 2017-11-14 at 08:55 +0800, Ming Lei wrote: > > > > > > Hi James, > > > > > > On Mon, Nov

Re: [PATCH V4] scsi_debugfs: fix crash in scsi_show_rq()

On Tue, 2017-11-14 at 08:55 +0800, Ming Lei wrote: > Hi James, > > On Mon, Nov 13, 2017 at 10:55:52AM -0800, James Bottomley wrote: > > > > On Sat, 2017-11-11 at 10:43 +0800, Ming Lei wrote: > > > > > > So from CPU1's review, cmd->cmnd is in a rem

Re: [PATCH V4] scsi_debugfs: fix crash in scsi_show_rq()

On Sat, 2017-11-11 at 10:43 +0800, Ming Lei wrote: > On Fri, Nov 10, 2017 at 08:51:58AM -0800, James Bottomley wrote: > > > > On Fri, 2017-11-10 at 17:01 +0800, Ming Lei wrote: > > > > > > cmd->cmnd can be allocated/freed dynamically in case of > > >

Re: [PATCH V4] scsi_debugfs: fix crash in scsi_show_rq()

not syncing: Fatal exception > [  252.963007] Dumping ftrace buffer: > [  252.963007](ftrace buffer empty) > [  252.963007] Kernel Offset: disabled > [  252.963007] ---[ end Kernel panic - not syncing: Fatal exception > > Fixes: 0eebd005dd07(scsi: Implement blk_mq_ops.show_rq())

Re: [PATCH V3] scsi_debugfs: fix crash in scsi_show_rq()

2.963007] Kernel Offset: disabled > [  252.963007] ---[ end Kernel panic - not syncing: Fatal exception > > Fixes: 0eebd005dd07(scsi: Implement blk_mq_ops.show_rq()) > Cc: Bart Van Assche <bart.vanass...@sandisk.com> > Cc: Omar Sandoval <osan...@fb.com> > Cc: Martin

Re: [PATCH V2] scsi_debugfs: fix crash in scsi_show_rq()

On Wed, 2017-11-08 at 09:15 +0800, Ming Lei wrote: > On Wed, Nov 08, 2017 at 01:06:44AM +, Bart Van Assche wrote: > > > > On Wed, 2017-11-08 at 08:59 +0800, Ming Lei wrote: > > > > > > On Tue, Nov 07, 2017 at 04:13:48PM +, Bart Van Assche wrote: > > > > > > > > On Tue, 2017-11-07 at

Re: [PATCH V2 00/20] blk-mq-sched: improve SCSI-MQ performance

On Fri, 2017-08-11 at 01:11 -0700, Christoph Hellwig wrote: > [+ Martin and linux-scsi] > > Given that we need this big pile and a few bfq fixes to avoid > major regressesions I'm tempted to revert the default to scsi-mq > for 4.14, but bring it back a little later for 4.15. > > What do you

Re: [PATCH] scsi: sanity check for timeout in sg_io()

On Wed, 2017-05-10 at 15:24 +0200, Hannes Reinecke wrote: > sg_io() is using msecs_to_jiffies() to convert a passed in timeout > value (in milliseconds) to a jiffies value. However, if the value > is too large msecs_to_jiffies() will return MAX_JIFFY_OFFSET, which > will be truncated to -2 and

Re: [PATCH 0/5] v2: block subsystem refcounter conversions

On Fri, 2017-04-21 at 14:30 -0700, Kees Cook wrote: > On Fri, Apr 21, 2017 at 2:27 PM, James Bottomley > <james.bottom...@hansenpartnership.com> wrote: > > On Fri, 2017-04-21 at 13:22 -0700, Kees Cook wrote: > > > On Fri, Apr 21, 2017 at 12:55 PM, Eric Biggers

Re: [PATCH 0/5] v2: block subsystem refcounter conversions

On Fri, 2017-04-21 at 13:22 -0700, Kees Cook wrote: > On Fri, Apr 21, 2017 at 12:55 PM, Eric Biggers > wrote: > > > > Of course, having extra checks behind a debug option is fine. > > > > But they should not be part of the base feature; the base > > > > feature should

Re: support ranges TRIM for libata

On Thu, 2017-03-23 at 14:55 +0100, Christoph Hellwig wrote: > On Thu, Mar 23, 2017 at 09:47:41AM -0400, James Bottomley wrote: > > > The current implementation already has the issue of that it does > > > corrupt user data reliably if the using SG_IO for WRIT

Re: support ranges TRIM for libata

On Wed, 2017-03-22 at 19:19 +0100, Christoph Hellwig wrote: > On Tue, Mar 21, 2017 at 02:59:01PM -0400, Tejun Heo wrote: > > I do like the fact that this is a lot simpler than the previous > > implementation but am not quite sure we want to deviate > > significantly from what we do for other

Re: [PATCH 1/4] block: Allow bdi re-registration

On Wed, 2017-03-08 at 17:55 -0500, Tejun Heo wrote: > Hello, > > On Wed, Mar 08, 2017 at 05:48:31PM +0100, Jan Kara wrote: > > @@ -710,6 +710,11 @@ static void cgwb_bdi_destroy(struct > > backing_dev_info *bdi) > > */ > > atomic_dec(>usage_cnt); > > wait_event(cgwb_release_wait,

Re: [bdi_unregister] 165a5e22fa INFO: task swapper:1 blocked for more than 120 seconds.

On Tue, 2017-03-07 at 15:41 +0100, Jan Kara wrote: > On Mon 06-03-17 09:25:42, James Bottomley wrote: > > On Mon, 2017-03-06 at 17:13 +0100, Jan Kara wrote: > > > On Mon 06-03-17 07:44:55, James Bottomley wrote: > ... > > > > > Sure. The call trace is

Re: [bdi_unregister] 165a5e22fa INFO: task swapper:1 blocked for more than 120 seconds.

On Mon, 2017-03-06 at 16:14 +0100, Jan Kara wrote: > On Mon 06-03-17 06:35:21, James Bottomley wrote: > > On Mon, 2017-03-06 at 13:01 +0100, Jan Kara wrote: > > > On Mon 06-03-17 11:27:33, Jan Kara wrote: > > > > Hi, > > > > > > > > On Sun 05-

Re: [bdi_unregister] 165a5e22fa INFO: task swapper:1 blocked for more than 120 seconds.

On Mon, 2017-03-06 at 17:13 +0100, Jan Kara wrote: > On Mon 06-03-17 07:44:55, James Bottomley wrote: > > On Mon, 2017-03-06 at 16:14 +0100, Jan Kara wrote: > > > On Mon 06-03-17 06:35:21, James Bottomley wrote: > > > > On Mon, 2017-03-06 at 13:01 +0100, Jan Kara wr

Re: [bdi_unregister] 165a5e22fa INFO: task swapper:1 blocked for more than 120 seconds.

On Mon, 2017-03-06 at 13:01 +0100, Jan Kara wrote: > On Mon 06-03-17 11:27:33, Jan Kara wrote: > > Hi, > > > > On Sun 05-03-17 10:21:11, Wu Fengguang wrote: > > > FYI next-20170303 is good while mainline is bad with this error. > > > The attached reproduce-* may help reproduce the issue. > > > >

Re: [LSF/MM TOPIC] do we really need PG_error at all?

On Mon, 2017-02-27 at 08:03 +1100, NeilBrown wrote: > On Sun, Feb 26 2017, James Bottomley wrote: > > > [added linux-scsi and linux-block because this is part of our error > > handling as well] > > On Sun, 2017-02-26 at 09:42 -0500, Jeff Layton wrote: > > >

Re: [LSF/MM TOPIC] do we really need PG_error at all?

[added linux-scsi and linux-block because this is part of our error handling as well] On Sun, 2017-02-26 at 09:42 -0500, Jeff Layton wrote: > Proposing this as a LSF/MM TOPIC, but it may turn out to be me just > not understanding the semantics here. > > As I was looking into -ENOSPC handling in

Re: [PATCH 0/5] block subsystem refcounter conversions

On Mon, 2017-02-20 at 17:56 +0100, Peter Zijlstra wrote: > On Mon, Feb 20, 2017 at 07:41:01AM -0800, James Bottomley wrote: > > On Mon, 2017-02-20 at 08:15 -0700, Jens Axboe wrote: > > > On 02/20/2017 04:16 AM, Elena Reshetova wrote: > > > > Now when new refcount_t t

Re: [GIT PULL] Block pull request for- 4.11-rc1

On Sun, 2017-02-19 at 18:15 -0700, Jens Axboe wrote: > On 02/19/2017 06:09 PM, Bart Van Assche wrote: > > On 02/19/2017 04:11 PM, Jens Axboe wrote: > > > - Removal of the BLOCK_PC support in struct request, and > > > refactoring of > > > carrying SCSI payloads in the block layer. This cleans up

Re: Manual driver binding and unbinding broken for SCSI

On Fri, 2017-02-17 at 16:30 -0800, Omar Sandoval wrote: > Hi, everyone, > > As per $SUBJECT, I can cause a crash on v4.10-rc8, Jens' block/for > -next, > and Jan's bdi branch [1] by doing this: > > # lsscsi > [0:0:0:0]diskQEMU QEMU HARDDISK2.5+ /dev/sda > # echo 0:0:0:0 >

Re: [lkp-robot] [scsi, block] 0dba1314d4: WARNING:at_fs/sysfs/dir.c:#sysfs_warn_dup

On Mon, 2017-02-06 at 21:09 -0700, Jens Axboe wrote: > On 02/06/2017 05:14 PM, James Bottomley wrote: > > On Sun, 2017-02-05 at 21:13 -0800, Dan Williams wrote: > > > On Sun, Feb 5, 2017 at 1:13 AM, Christoph Hellwig <h...@lst.de> > > > wrote: > > > &g

Re: [Lsf-pc] LSF/MM Question

On Tue, 2017-02-07 at 16:09 +, Jim Mostek via Lsf-pc wrote: > wondering about the upcoming Linux Storage Filesystem & MM summint in > March. LSF/MM Question > > What presentations are there so far? LSF/MM is not really a conference, it's a summit. That means it's going to be discussion

Re: [lkp-robot] [scsi, block] 0dba1314d4: WARNING:at_fs/sysfs/dir.c:#sysfs_warn_dup

On Sun, 2017-02-05 at 21:13 -0800, Dan Williams wrote: > On Sun, Feb 5, 2017 at 1:13 AM, Christoph Hellwig wrote: > > Dan, > > > > can you please quote your emails? I can't find any content > > inbetween all these quotes. > > Sorry, I'm using gmail, but I'll switch to attaching

Re: remove the cmd_type field from struct request

On Tue, 2017-01-31 at 10:02 -0800, Jens Axboe wrote: > On 01/31/2017 07:57 AM, Christoph Hellwig wrote: > > [1] which were a pain in the ass to untangle and debug during > > development, it's really time for it to die.. > > Outside of the patch series in question, how to we expedite the >

Re: [Lsf-pc] [LSF/MM TOPIC] [LSF/MM ATTEND] md raid general discussion

On Mon, 2017-01-16 at 11:33 +0800, Guoqing Jiang wrote: > > On 01/10/2017 12:38 AM, Coly Li wrote: > > Hi Folks, > > > > I'd like to propose a general md raid discussion, it is quite > > necessary for most of active md raid developers sit together to > > discuss current challenge of Linux

Re: [Lsf-pc] [LSF/MM ATTEND] OCSSDs - SMR, Hierarchical Interface, and Vector I/Os

On Thu, 2017-01-12 at 11:35 +0900, Damien Le Moal wrote: > > Just a note for the poor admin looking after the lists: to find all > > the ATTEND and TOPIC requests for the lists I fold up the threads > > to the top. If you frame your attend request as a reply, it's > > possible it won't get

Re: [Lsf-pc] [LSF/MM ATTEND] OCSSDs - SMR, Hierarchical Interface, and Vector I/Os

On Thu, 2017-01-12 at 10:33 +0900, Damien Le Moal wrote: > Hello, > > A long discussion on the list followed this initial topic proposal > from Matias. I think this is a worthy topic to discuss at LSF in > order to steer development of the zoned block device interface in the > right direction.

Re: [LSF/MM TOPIC] Un-addressable device memory and block/fs implications

On Tue, 2016-12-13 at 13:55 -0500, Jerome Glisse wrote: > On Tue, Dec 13, 2016 at 10:20:52AM -0800, James Bottomley wrote: > > On Tue, 2016-12-13 at 13:15 -0500, Jerome Glisse wrote: > > > I would like to discuss un-addressable device memory in the > > > context &g

Re: [LSF/MM TOPIC] Un-addressable device memory and block/fs implications

On Tue, 2016-12-13 at 13:15 -0500, Jerome Glisse wrote: > I would like to discuss un-addressable device memory in the context > of filesystem and block device. Specificaly how to handle write-back, > read, ... when a filesystem page is migrated to device memory that > CPU can not access. > > I

Re: LSF/MM 2017: Call for Proposals

On Thu, 2016-12-08 at 13:26 +0100, Michal Hocko wrote: > On Wed 07-12-16 06:57:06, James Bottomley wrote: > [...] > > Just on this point, since there seems to be a lot of confusion: lsf > > -pc > > is the list for contacting the programme committee, so

Re: LSF/MM 2017: Call for Proposals

On Thu, 2016-12-01 at 09:11 -0500, Jeff Layton wrote: > 1) Proposals for agenda topics should be sent before January 15th, > 2016 to: > > lsf...@lists.linux-foundation.org > > and cc the Linux list or lists that are relevant for the topic in > question: > > ATA:

Re: [PATCH 9/9] [RFC] nvme: Fix a race condition

On Tue, 2016-09-27 at 09:43 -0700, Bart Van Assche wrote: > On 09/27/2016 09:31 AM, Steve Wise wrote: > > > @@ -2079,11 +2075,15 @@ EXPORT_SYMBOL_GPL(nvme_kill_queues); > > > void nvme_stop_queues(struct nvme_ctrl *ctrl) > > > { > > > struct nvme_ns *ns; > > > + struct request_queue *q; > > >

Re: Time to make dynamically allocated devt the default for scsi disks?

On Sat, 2016-08-13 at 11:27 -0700, Dan Williams wrote: > On Sat, Aug 13, 2016 at 10:43 AM, James Bottomley > <james.bottom...@hansenpartnership.com> wrote: > > On Sat, 2016-08-13 at 09:29 -0700, Dan Williams wrote: > > > On Sat, Aug 13, 2016 at 8:23 AM, James Bo

Re: Time to make dynamically allocated devt the default for scsi disks?

On Sat, 2016-08-13 at 09:29 -0700, Dan Williams wrote: > On Sat, Aug 13, 2016 at 8:23 AM, James Bottomley > <james.bottom...@hansenpartnership.com> wrote: > > It does? The race is the fact that the parent can be removed > > before the child meaning if the parent name

Re: Time to make dynamically allocated devt the default for scsi disks?

On Fri, 2016-08-12 at 21:57 -0700, Dan Williams wrote: > On Fri, Aug 12, 2016 at 5:29 PM, Dan Williams < > dan.j.willi...@intel.com> wrote: > > On Fri, Aug 12, 2016 at 5:17 PM, James Bottomley > > <james.bottom...@hansenpartnership.com> wrote: > > > On Fri,

Re: Time to make dynamically allocated devt the default for scsi disks?

On Fri, 2016-08-12 at 14:29 -0700, Dan Williams wrote: > Before spending effort trying to flush the destruction of old bdi > instances before new ones are registered, is it rather time to > complete the conversion of sd to only use dynamically allocated devt? Do we have to go that far? Surely