Re: [PATCH v2 3/7] drivers/base: Probe devices concurrently if requested by the driver

n > Cc: Johannes Thumshirn > Cc: Christoph Hellwig > Cc: Greg Kroah-Hartman > Cc: Dan Williams > Signed-off-by: Bart Van Assche > --- > drivers/base/bus.c | 3 +-- > drivers/base/dd.c | 49 ++ > 2 files changed, 50 inser

Re: [PATCH 1/2 v2] libsas: remove irq save in sas_ata_qc_issue()

hey were disabled and remain disabled. Therefore remove the operations > which do not change the behaviour. > > Signed-off-by: Sebastian Andrzej Siewior Acked-by: Dan Williams

Re: [PATCH 0/2 REPOST] remove unneded irq save

On Thu, Jun 14, 2018 at 7:30 AM, Sebastian Andrzej Siewior wrote: > On 2018-06-12 08:46:38 [-0700], Dan Williams wrote: >> On Tue, Jun 12, 2018 at 8:04 AM, John Garry wrote: >> >> We had this comment for 6 years or so and nothing happend. What makes >> >>

Re: [PATCH 0/2 REPOST] remove unneded irq save

On Tue, Jun 12, 2018 at 8:04 AM, John Garry wrote: > On 12/06/2018 15:31, Sebastian Andrzej Siewior wrote: >> >> On 2018-06-12 13:54:36 [+0100], John Garry wrote: >>> >>> +Dan >>> >>> On 11/06/2018 19:23, Sebastian Andrzej Siewior wrote: On 2018-06-11 18:12:55 [+0100], John Garry wrote:

Re: [PATCH] scsi: libsas: add transport class for ATA devices

On Mon, Mar 26, 2018 at 2:27 AM, Jason Yan wrote: > Now ata devices attached with sas controller do not have transport > class, so that we can not see any information of these ata devices in > /sys/class/ata_port(or ata_link or ata_device). > > Add transport class for the ata

Re: [PATCH v3] scsi: libsas: defer ata device eh commands to libata

gt; [] kthread+0x10c/0x138 > [] ret_from_fork+0x10/0x18 > > If ata qc leaked too many, ata tag allocation will fail and io blocked > for ever. > > As suggested by Dan Williams, defer ata device commands to libata and > merge sas_eh_finish_cmd() with sas_eh_defer_cmd().

Re: [PATCH v2] scsi: libsas: defer ata device eh commands to libata

gt; [] kthread+0x10c/0x138 > [] ret_from_fork+0x10/0x18 > > If ata qc leaked too many, ata tag allocation will fail and io blocked > for ever. > > As suggested by Dan Williams, defer ata device commands to libata and > merge sas_eh_finish_cmd() with sas_eh_defer_cmd().

Re: [PATCH] scsi: libsas: defer ata device eh commands to libata

On Tue, Mar 6, 2018 at 10:04 AM, Martin K. Petersen wrote: > >> When ata device doing EH, some commands still attached with tasks are not >> passed to libata when abort failed or recover failed, so libata did not >> handle these commands. After these commands done, sas

Re: [PATCH v2 00/19] prevent bounds-check bypass via speculative execution

On Thu, Jan 18, 2018 at 5:18 AM, Will Deacon <will.dea...@arm.com> wrote: > Hi Dan, Linus, > > On Thu, Jan 11, 2018 at 05:41:08PM -0800, Dan Williams wrote: >> On Thu, Jan 11, 2018 at 5:19 PM, Linus Torvalds >> <torva...@linux-foundation.org> wrote: >>

Re: [PATCH v2 17/19] qla2xxx: prevent bounds-check bypass via speculative execution

On Thu, Jan 11, 2018 at 5:19 PM, James Bottomley <j...@linux.vnet.ibm.com> wrote: > On Thu, 2018-01-11 at 16:47 -0800, Dan Williams wrote: >> Static analysis reports that 'handle' may be a user controlled value >> that is used as a data dependency to read 'sp' from the >

Re: [PATCH v2 00/19] prevent bounds-check bypass via speculative execution

On Thu, Jan 11, 2018 at 5:19 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > On Thu, Jan 11, 2018 at 4:46 PM, Dan Williams <dan.j.willi...@intel.com> > wrote: >> >> This series incorporates Mark Rutland's latest ARM changes and adds >

[PATCH v2 00/19] prevent bounds-check bypass via speculative execution

k/2018/01/reading-privileged-memory-with-side.html [3]: https://spectreattack.com/spectre.pdf [4]: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=b2157399cc98 --- Dan Williams (16): x86: implement ifence() x86: implement ifence_array_ptr() and a

[PATCH v2 17/19] qla2xxx: prevent bounds-check bypass via speculative execution

Cc: "James E.J. Bottomley" <j...@linux.vnet.ibm.com> Cc: "Martin K. Petersen" <martin.peter...@oracle.com> Cc: linux-scsi@vger.kernel.org Signed-off-by: Elena Reshetova <elena.reshet...@intel.com> Signed-off-by: Dan Williams <dan.j.willi...@intel.co

Re: [PATCH 10/18] qla2xxx: prevent bounds-check bypass via speculative execution

On Sat, Jan 6, 2018 at 1:03 AM, Greg KH <gre...@linuxfoundation.org> wrote: > On Fri, Jan 05, 2018 at 05:10:48PM -0800, Dan Williams wrote: >> Static analysis reports that 'handle' may be a user controlled value >> that is used as a data dependency to read 'sp' from the >

Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

On Thu, Jan 11, 2018 at 1:54 AM, Jiri Kosina <ji...@kernel.org> wrote: > On Tue, 9 Jan 2018, Josh Poimboeuf wrote: > >> On Tue, Jan 09, 2018 at 11:44:05AM -0800, Dan Williams wrote: >> > On Tue, Jan 9, 2018 at 11:34 AM, Jiri Kosina <ji...@kernel.org> wrote: >&g

Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

On Tue, Jan 9, 2018 at 11:34 AM, Jiri Kosina <ji...@kernel.org> wrote: > On Fri, 5 Jan 2018, Dan Williams wrote: > > [ ... snip ... ] >> Andi Kleen (1): >> x86, barrier: stop speculation for failed access_ok >> >> Dan Williams (13): >> x8

Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

On Sat, Jan 6, 2018 at 11:37 AM, Dan Williams <dan.j.willi...@intel.com> wrote: > On Fri, Jan 5, 2018 at 5:09 PM, Dan Williams <dan.j.willi...@intel.com> wrote: >> Quoting Mark's original RFC: >> >> "Recently, Google Project Zero discovered several cl

Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

On Fri, Jan 5, 2018 at 5:09 PM, Dan Williams <dan.j.willi...@intel.com> wrote: > Quoting Mark's original RFC: > > "Recently, Google Project Zero discovered several classes of attack > against speculative execution. One of these, known as variant-1, allows > explicit bo

Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

On Fri, Jan 5, 2018 at 6:22 PM, Eric W. Biederman <ebied...@xmission.com> wrote: > Dan Williams <dan.j.willi...@intel.com> writes: > >> Quoting Mark's original RFC: >> >> "Recently, Google Project Zero discovered several classes of attack >> aga

[PATCH 00/18] prevent bounds-check bypass via speculative execution

for failed access_ok Dan Williams (13): x86: implement nospec_barrier() [media] uvcvideo: prevent bounds-check bypass via speculative execution carl9170: prevent bounds-check bypass via speculative execution p54: prevent bounds-check bypass via speculative execution qla

[PATCH 10/18] qla2xxx: prevent bounds-check bypass via speculative execution

er...@oracle.com> Cc: linux-scsi@vger.kernel.org Signed-off-by: Elena Reshetova <elena.reshet...@intel.com> Signed-off-by: Dan Williams <dan.j.willi...@intel.com> --- drivers/scsi/qla2xxx/qla_mr.c | 15 +-- 1 file changed, 9 insertions(+), 6 deletions(-) diff --git

Re: [PATCH 1/2] libsas: Don't process sas events in static works

On Fri, May 19, 2017 at 11:39 PM, Yijing Wang wrote: > Now libsas hotplug work is static, LLDD driver queue > the hotplug work into shost->work_q. If LLDD driver > burst post lots hotplug events to libsas, the hotplug > events may pending in the workqueue like > >

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Thu, Apr 20, 2017 at 4:07 PM, Stephen Bates wrote: >>> Yes, this makes sense I think we really just want to distinguish host >>> memory or not in terms of the dev_pagemap type. >> >>> I would like to see mutually exclusive flags for host memory (or not) and >>>

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Thu, Apr 20, 2017 at 1:43 PM, Stephen Bates wrote: > >> Yes, this makes sense I think we really just want to distinguish host >> memory or not in terms of the dev_pagemap type. > > I would like to see mutually exclusive flags for host memory (or not) and > persistence

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Wed, Apr 19, 2017 at 3:55 PM, Logan Gunthorpe wrote: > > > On 19/04/17 02:48 PM, Jason Gunthorpe wrote: >> On Wed, Apr 19, 2017 at 01:41:49PM -0600, Logan Gunthorpe wrote: >> But.. it could point to a GPU and the GPU struct device could have a proxy dma_ops like

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Wed, Apr 19, 2017 at 11:41 AM, Logan Gunthorpe <log...@deltatee.com> wrote: > > > On 19/04/17 12:30 PM, Dan Williams wrote: >> Letting others users do the container_of() arrangement means that >> struct page_map needs to become public and move into struct >> dev

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Wed, Apr 19, 2017 at 11:19 AM, Logan Gunthorpe <log...@deltatee.com> wrote: > > > On 19/04/17 12:11 PM, Logan Gunthorpe wrote: >> >> >> On 19/04/17 11:41 AM, Dan Williams wrote: >>> No, not quite ;-). I still don't think we should require the non-HMM

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Wed, Apr 19, 2017 at 10:32 AM, Jerome Glisse <jgli...@redhat.com> wrote: > On Wed, Apr 19, 2017 at 10:01:23AM -0700, Dan Williams wrote: >> On Wed, Apr 19, 2017 at 9:48 AM, Logan Gunthorpe <log...@deltatee.com> wrote: >> > >> > >> > On 1

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Wed, Apr 19, 2017 at 9:48 AM, Logan Gunthorpe wrote: > > > On 19/04/17 09:55 AM, Jason Gunthorpe wrote: >> I was thinking only this one would be supported with a core code >> helper.. > > Pivoting slightly: I was looking at how HMM uses ZONE_DEVICE. They add a > type flag

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Tue, Apr 18, 2017 at 3:56 PM, Logan Gunthorpe <log...@deltatee.com> wrote: > > > On 18/04/17 04:50 PM, Dan Williams wrote: >> On Tue, Apr 18, 2017 at 3:48 PM, Logan Gunthorpe <log...@deltatee.com> wrote: >>> >>> >>> On 18/04/17 04:28 P

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Tue, Apr 18, 2017 at 3:46 PM, Benjamin Herrenschmidt <b...@kernel.crashing.org> wrote: > On Tue, 2017-04-18 at 10:27 -0700, Dan Williams wrote: >> > FWIW, RDMA probably wouldn't want to use a p2mem device either, we >> > already have APIs that map BAR memory to

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Tue, Apr 18, 2017 at 3:48 PM, Logan Gunthorpe <log...@deltatee.com> wrote: > > > On 18/04/17 04:28 PM, Dan Williams wrote: >> Unlike the pci bus address offset case which I think is fundamental to >> support since shipping archs do this today, I think it is ok

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Tue, Apr 18, 2017 at 3:15 PM, Logan Gunthorpe <log...@deltatee.com> wrote: > > > On 18/04/17 03:36 PM, Dan Williams wrote: >> On Tue, Apr 18, 2017 at 2:22 PM, Jason Gunthorpe >> <jguntho...@obsidianresearch.com> wrote: >>> On Tue, Apr 18, 2017 at 02:

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Tue, Apr 18, 2017 at 2:22 PM, Jason Gunthorpe <jguntho...@obsidianresearch.com> wrote: > On Tue, Apr 18, 2017 at 02:11:33PM -0700, Dan Williams wrote: >> > I think this opens an even bigger can of worms.. >> >> No, I don't think it does. You'd only shim whe

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Tue, Apr 18, 2017 at 2:03 PM, Jason Gunthorpe <jguntho...@obsidianresearch.com> wrote: > On Tue, Apr 18, 2017 at 12:48:35PM -0700, Dan Williams wrote: > >> > Yes, I noticed this problem too and that makes sense. It just means >> > every dma_ops will probably

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Tue, Apr 18, 2017 at 1:29 PM, Jerome Glisse wrote: >> On Tue, Apr 18, 2017 at 12:35 PM, Logan Gunthorpe >> wrote: >> > >> > >> > On 18/04/17 01:01 PM, Jason Gunthorpe wrote: >> >> Ultimately every dma_ops will need special code to support P2P with >>

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Tue, Apr 18, 2017 at 12:35 PM, Logan Gunthorpe wrote: > > > On 18/04/17 01:01 PM, Jason Gunthorpe wrote: >> Ultimately every dma_ops will need special code to support P2P with >> the special hardware that ops is controlling, so it makes some sense >> to start by pushing

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Tue, Apr 18, 2017 at 11:00 AM, Jason Gunthorpe <jguntho...@obsidianresearch.com> wrote: > On Tue, Apr 18, 2017 at 10:27:47AM -0700, Dan Williams wrote: >> > FWIW, RDMA probably wouldn't want to use a p2mem device either, we >> > already have APIs that map BAR memo

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Tue, Apr 18, 2017 at 9:45 AM, Jason Gunthorpe wrote: > On Mon, Apr 17, 2017 at 08:23:16AM +1000, Benjamin Herrenschmidt wrote: > >> Thanks :-) There's a reason why I'm insisting on this. We have constant >> requests for this today. We have hacks in the GPU

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Mon, Apr 17, 2017 at 9:52 AM, Logan Gunthorpe wrote: > > > On 17/04/17 01:20 AM, Benjamin Herrenschmidt wrote: >> But is it ? For example take a GPU, does it, in your scheme, need an >> additional "p2pmem" child ? Why can't the GPU driver just use some >> helper to

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Sat, Apr 15, 2017 at 8:01 PM, Benjamin Herrenschmidt <b...@kernel.crashing.org> wrote: > On Sat, 2017-04-15 at 15:09 -0700, Dan Williams wrote: >> I'm wondering, since this is limited to support behind a single >> switch, if you could have a software-iommu hanging off

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Sat, Apr 15, 2017 at 10:36 PM, Logan Gunthorpe wrote: > > > On 15/04/17 04:17 PM, Benjamin Herrenschmidt wrote: >> You can't. If the iommu is on, everything is remapped. Or do you mean >> to have dma_map_* not do a remapping ? > > Well, yes, you'd have to change the code

Re: [RFC 0/8] Copy Offload with Peer-to-Peer PCI Memory

On Sat, Apr 15, 2017 at 10:41 AM, Logan Gunthorpe wrote: > Thanks, Benjamin, for the summary of some of the issues. > > On 14/04/17 04:07 PM, Benjamin Herrenschmidt wrote >> So I assume the p2p code provides a way to address that too via special >> dma_ops ? Or wrappers ? > >

Re: [PATCH v2] scsi: ses: don't get power status of SES device slot on probe

d be curious. > > Well, to handle that more properly, set the initial power state > value to '-1' (i.e., uninitialized) instead of '1' (power 'on'), > and check for it in that callback which may do an direct access > to the field value _if_ a callback function is not defined. > > Signed-off-by: Mauricio Faria de Oliveira <mauri...@linux.vnet.ibm.com> > Fixes: 08024885a2a3 ("ses: Add power_status to SES device slot") Reviewed-by: Dan Williams <dan.j.willi...@intel.com>

Re: [PATCH] scsi: ses: don't get power status of SES device slot on probe

On Wed, Apr 5, 2017 at 6:13 AM, Mauricio Faria de Oliveira <mauri...@linux.vnet.ibm.com> wrote: > Hi Dan, > > Thanks for reviewing. > > On 04/04/2017 06:07 PM, Dan Williams wrote: >>> >>> @@ -594,6 +594,10 @@ static ssize_t get_compone

Re: [PATCH] scsi: ses: don't get power status of SES device slot on probe

On Wed, Mar 29, 2017 at 6:02 PM, Mauricio Faria de Oliveira wrote: > The commit 08024885a2a3 ("ses: Add power_status to SES device slot") > introduced the 'power_status' attribute to enclosure components and > the associated callbacks. > > There are 2 callbacks

Re: [RFC 5/8] scatterlist: Modify SG copy functions to support io memory.

On Mon, Apr 3, 2017 at 4:12 PM, Logan Gunthorpe <log...@deltatee.com> wrote: > > > On 03/04/17 04:47 PM, Dan Williams wrote: >> I wouldn't necessarily conflate supporting pfn_t in the scatterlist >> with the stalled stuct-page-less DMA effor. A pfn_t_to_page() &g

Re: [RFC 5/8] scatterlist: Modify SG copy functions to support io memory.

On Mon, Apr 3, 2017 at 3:10 PM, Logan Gunthorpe <log...@deltatee.com> wrote: > > > On 03/04/17 03:44 PM, Dan Williams wrote: >> On Mon, Apr 3, 2017 at 2:20 PM, Logan Gunthorpe <log...@deltatee.com> wrote: >>> Hi Christoph, >>> >>> What are yo

Re: [RFC 5/8] scatterlist: Modify SG copy functions to support io memory.

On Mon, Apr 3, 2017 at 2:20 PM, Logan Gunthorpe wrote: > Hi Christoph, > > What are your thoughts on an approach like the following untested > draft patch. > > The patch (if fleshed out) makes it so iomem can be used in an sgl > and WARN_ONs will occur in places where drivers

Re: [PATCH 4/4] Revert "scsi, block: fix duplicate bdi name registration crashes"

; > [1]: http://marc.info/?l=linux-block=148554717109098=2 > > Signed-off-by: Jan Kara <j...@suse.cz> Acked-by: Dan Williams <dan.j.willi...@intel.com>

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

On Wed, Feb 8, 2017 at 4:08 PM, James Bottomley <james.bottom...@hansenpartnership.com> wrote: > On Mon, 2017-02-06 at 21:42 -0800, Dan Williams wrote: [..] >> ...but it reproduces on current mainline with the same config. I >> haven't spotted what makes scsi_debug behave l

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

On Mon, Feb 6, 2017 at 8:09 PM, Jens Axboe <ax...@fb.com> 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: >>>>

Re: [RFC PATCH] scsi, block: fix duplicate bdi name registration crashes

On Mon, Jan 30, 2017 at 4:24 AM, Christoph Hellwig wrote: > Hi Dan, > > this looks mostly fine to me. A few code comments below, but except > for this there is another issue with it: We still have drivers > that share a single request_queue for multiple gendisks, so I wonder scsi

Re: [RFC PATCH] scsi: libsas: fix WARN on device removal

On Mon, Nov 21, 2016 at 7:16 AM, John Garry wrote: > @Maintainers, would you be willing to accept this patch as an interim > fix > for the dastardly WARN while we try to fix the flutter issue? To me this adds a bug to quiet a benign, albeit

Re: [RFC PATCH] scsi: libsas: fix WARN on device removal

On Fri, Nov 18, 2016 at 1:00 AM, John Garry <john.ga...@huawei.com> wrote: > On 18/11/2016 01:53, Dan Williams wrote: >> >> On Thu, Nov 17, 2016 at 7:23 AM, John Garry <john.ga...@huawei.com> wrote: >>> >>> On 11/11/2016 08:49, wangyijing wrote: >&g

Re: [RFC PATCH] scsi: libsas: fix WARN on device removal

On Thu, Nov 17, 2016 at 7:23 AM, John Garry wrote: > On 11/11/2016 08:49, wangyijing wrote: > > I have not seen the flutter issue. I am just trying to solve the > horrible WARN dump. > However I do understand that there may be a issue related to how we >

Re: [RFC PATCH] scsi: libsas: fix WARN on device removal

On Wed, Nov 9, 2016 at 11:09 AM, Dan Williams <dan.j.willi...@intel.com> wrote: > On Wed, Nov 9, 2016 at 9:36 AM, John Garry <john.ga...@huawei.com> wrote: >> On 09/11/2016 12:28, John Garry wrote: >>> >>> On 03/11/2016 14:58, John Garry wrote: >>>&

Re: [RFC PATCH] scsi: libsas: fix WARN on device removal

On Wed, Nov 9, 2016 at 9:36 AM, John Garry wrote: > On 09/11/2016 12:28, John Garry wrote: >> >> On 03/11/2016 14:58, John Garry wrote: >>> >>> The following patch introduces an annoying WARN >>> when a device is removed from the SAS topology: >>> [SCSI] libsas: prevent

Re: [PATCH v4 1/4] block: Add iocontext priority to request

On Thu, Oct 13, 2016 at 1:24 PM, Jens Axboe <ax...@kernel.dk> wrote: > On 10/13/2016 02:19 PM, Dan Williams wrote: >> >> On Thu, Oct 13, 2016 at 1:09 PM, Jens Axboe <ax...@kernel.dk> wrote: >>> >>> On 10/13/2016 02:06 PM, Dan Williams wrote: >>

Re: [PATCH v4 1/4] block: Add iocontext priority to request

On Thu, Oct 13, 2016 at 1:09 PM, Jens Axboe <ax...@kernel.dk> wrote: > On 10/13/2016 02:06 PM, Dan Williams wrote: >> >> On Thu, Oct 13, 2016 at 12:53 PM, Adam Manzanares >> <adam.manzana...@hgst.com> wrote: >>> >>> Patch adds an association betwe

Re: [PATCH v4 1/4] block: Add iocontext priority to request

On Thu, Oct 13, 2016 at 12:53 PM, Adam Manzanares wrote: > Patch adds an association between iocontext ioprio and the ioprio of a > request. This value is set in blk_rq_set_prio which takes the request and > the ioc as arguments. If the ioc is valid in blk_rq_set_prio

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

On Mon, Aug 29, 2016 at 11:16 AM, Bart Van Assche wrote: > On 08/14/2016 10:21 AM, James Bottomley wrote: >> diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c >> index d3e852a..222771d 100644 >> --- a/drivers/scsi/sd.c >> +++ b/drivers/scsi/sd.c >> @@ -3000,7 +3000,13

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

[ adding Bart back to the cc ] On Sun, Aug 14, 2016 at 11:08 AM, Dan Williams <dan.j.willi...@intel.com> wrote: > On Sun, Aug 14, 2016 at 10:20 AM, James Bottomley > <james.bottom...@hansenpartnership.com> wrote: [..] > I like it. I still think the bdi registration code

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

On Sun, Aug 14, 2016 at 10:20 AM, James Bottomley <james.bottom...@hansenpartnership.com> wrote: > 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: >> &g

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

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 Bottomley >> <james.bottom...@hansenpartnership.com> wrote: >>

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

On Sat, Aug 13, 2016 at 11:27 AM, Dan Williams <dan.j.willi...@intel.com> wrote: > On Sat, Aug 13, 2016 at 10:43 AM, James Bottomley [..] >> Um, so this patch doesn't fix the problem. It merely makes the lifetime >> rules correct so the problem can then be fixed at the scsi le

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

On Sat, Aug 13, 2016 at 8:23 AM, James Bottomley <james.bottom...@hansenpartnership.com> wrote: > 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

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

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, 2016-08-12 at 14:29 -0700, Dan Williams wrote: >>> Before spending effor

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

On Fri, Aug 12, 2016 at 5:17 PM, James Bottomley <james.bottom...@hansenpartnership.com> wrote: > 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 register

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

On Fri, Aug 12, 2016 at 2:35 PM, Bart Van Assche <bart.vanass...@sandisk.com> wrote: > On 08/12/2016 02:29 PM, Dan Williams wrote: >> >> ...or, for that matter, any block device driver on a bus that supports >> hotplug? >> >> In 4.8 Jens merged the follo

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

...or, for that matter, any block device driver on a bus that supports hotplug? In 4.8 Jens merged the following fix for a crash that was triggered by repeatedly reconfiguring a libnvdimm namespace causing it to destroy and create disks (rapid hotplug). df08c32ce3be block: fix bdi vs gendisk

Re: [PATCH V2 resend] libata:fix kernel panic when hotplug

On Mon, Jun 20, 2016 at 6:22 PM, Martin K. Petersen wrote: >> "Tejun" == Tejun Heo writes: > >>> In fact,we don't need libata to deal with hotplug in sas environment. >>> So we can't run ata hotplug task when ata port is sas host. > > Tejun>

Re: [PATCH v2 1/2] scsi: fix race between simultaneous decrements of ->host_failed

On Tue, May 31, 2016 at 8:21 PM, Dan Williams <dan.j.willi...@intel.com> wrote: > On Tue, May 31, 2016 at 1:38 AM, Wei Fang <fangw...@huawei.com> wrote: >> sas_ata_strategy_handler() adds the works of the ata error handler >> to system_unbound_wq. This workqueue asy

Re: [PATCH v2 1/2] scsi: fix race between simultaneous decrements of ->host_failed

errors after that won't be handled forever. > > Use atomic type for ->host_failed to fix this race. > > This fixes the problem introduced in > commit 50824d6c5657 ("[SCSI] libsas: async ata-eh"). > > Reviewed-by: Christoph Hellwig <h...@infradead.org> &g

Re: [PATCH v4 0/3] Badblock tracking for gendisks

Hi Jens, Are you on-board with this approach? Any concerns with me carrying this through the nvdimm tree along with our other pending error-handling enabling? -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More

Re: [PATCH v2 1/3] badblocks: Add core badblock management code

On Tue, Dec 8, 2015 at 1:08 PM, Verma, Vishal L wrote: > On Wed, 2015-12-09 at 08:03 +1100, NeilBrown wrote: >> On Sat, Dec 05 2015, Verma, Vishal L wrote: >> > > >> > > > +int badblocks_clear(struct badblocks *bb, sector_t s, int >> > > > sectors) >> > > > +{ >> > >

Re: [PATCH 2/3] block: Add badblock management for gendisks

On Tue, Nov 24, 2015 at 12:10 PM, Verma, Vishal L wrote: > On Tue, 2015-11-24 at 14:14 -0500, Jeff Moyer wrote: >> >> I'm not sure whether it makes sense to continue without badblock >> management for the RAID code. I was hoping Neil would comment on >> that. >> >>

Re: [PATCH 2/2] Restart list search after unlock in scsi_remove_target

On Wed, Nov 4, 2015 at 2:44 PM, James Bottomley <james.bottom...@hansenpartnership.com> wrote: [..] > The fundamental problem with this is how have the conditions that caused > us to move away from list restart: > > commit bc3f02a795d3b4faa99d37390174be2a75d091bd > Au

Re: [PATCH] scsi: restart list search after unlock in scsi_remove_target

On Mon, Oct 19, 2015 at 8:56 AM, Christoph Hellwig wrote: > On Mon, Oct 19, 2015 at 08:36:23AM -0700, Bart Van Assche wrote: >> Thanks for looking into this. However, I think we need a motivation in the >> patch description why this patch does not reintroduce the soft lockup >>

Re: [PATCH] scsi: fix scsi_error_handler vs. scsi_host_dev_release race

mho...@suse.com Acked-by: Dan Williams dan.j.willi...@intel.com -- 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

Re: [for 4.1 PATCH resend] libsas: fix sysfs group not found warnings at port teardown time

On Mon, Jul 27, 2015 at 8:17 AM, James Bottomley james.bottom...@hansenpartnership.com wrote: On Wed, 2015-07-22 at 14:08 -0700, Dan Williams wrote: On Wed, Jul 22, 2015 at 11:28 AM, James Bottomley james.bottom...@hansenpartnership.com wrote: } void sas_device_set_phy(struct

Re: [for 4.1 PATCH resend] libsas: fix sysfs group not found warnings at port teardown time

On Mon, Jul 27, 2015 at 10:11 AM, James Bottomley james.bottom...@hansenpartnership.com wrote: On Mon, 2015-07-27 at 08:48 -0700, Dan Williams wrote: On Mon, Jul 27, 2015 at 8:17 AM, James Bottomley james.bottom...@hansenpartnership.com wrote: On Wed, 2015-07-22 at 14:08 -0700, Dan Williams

Re: [for 4.1 PATCH resend] libsas: fix sysfs group not found warnings at port teardown time

On Mon, Jul 27, 2015 at 11:07 AM, James Bottomley james.bottom...@hansenpartnership.com wrote: On Mon, 2015-07-27 at 08:48 -0700, Dan Williams wrote: On Mon, Jul 27, 2015 at 8:17 AM, James Bottomley james.bottom...@hansenpartnership.com wrote: On Wed, 2015-07-22 at 14:08 -0700, Dan Williams

Re: [for 4.1 PATCH resend] libsas: fix sysfs group not found warnings at port teardown time

On Mon, Jul 27, 2015 at 11:38 AM, James Bottomley james.bottom...@hansenpartnership.com wrote: No, that seems to be the intent of the prior code. The reason port visibility goes immediately (along with all associated phys), is that the port is ready for reuse as soon as sas_deform_port()

Re: [for 4.1 PATCH resend] libsas: fix sysfs group not found warnings at port teardown time

On Wed, Jul 22, 2015 at 11:28 AM, James Bottomley james.bottom...@hansenpartnership.com wrote: On Wed, 2015-06-17 at 23:22 -0400, Dan Williams wrote: Praveen reports: After some debugging this is what I have found sas_phye_loss_of_signal gets triggered on phy_event from mvsas

[PATCH resend] libsas: fix sysfs group not found warnings at port teardown time

now exposes this problem. Libsas should delete all the devices from rphy down before deleting the parent port. Cc: sta...@vger.kernel.org Reported-by: Praveen Murali pmur...@logicube.com Tested-by: Praveen Murali pmur...@logicube.com Reviewed-by: Hannes Reinecke h...@suse.de Signed-off-by: Dan

[for 4.1 PATCH resend] libsas: fix sysfs group not found warnings at port teardown time

now exposes this problem. Libsas should delete all the devices from rphy down before deleting the parent port. Cc: sta...@vger.kernel.org Reported-by: Praveen Murali pmur...@logicube.com Tested-by: Praveen Murali pmur...@logicube.com Signed-off-by: Dan Williams dan.j.willi...@intel.com --- drivers

[PATCH v2] libsas: fix sysfs group not found warnings at port teardown time

below sas_port, but recent sysfs changes now exposes this problem. Libsas should delete all the devices from rphy down before deleting the parent port. Cc: sta...@vger.kernel.org Reported-by: Praveen Murali pmur...@logicube.com Tested-by: Praveen Murali pmur...@logicube.com Signed-off-by: Dan

[PATCH] libsas: fix sysfs group not found warnings at port teardown time

-by: Dan Williams dan.j.willi...@intel.com --- drivers/scsi/libsas/sas_discover.c |6 +++--- drivers/scsi/libsas/sas_port.c |1 - 2 files changed, 3 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/libsas/sas_discover.c b/drivers/scsi/libsas/sas_discover.c index 60de66252fa2

Re: [PATCH] libsas: remove task_collector mode

. Signed-off-by: Christoph Hellwig h...@lst.de Acked-by: Dan Williams dan.j.willi...@intel.com -- 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

Re: [RFC] drop libsas task collector mode?

On Tue, Nov 4, 2014 at 10:58 AM, Christoph Hellwig h...@infradead.org wrote: The task collector mode in libsas implements internal queueing in libsas, which is somethign we usualy try to avoid, and doesn't seem to get much exposure as it's only supported as a non-default option in two drivers.

Re: [PATCH 1/3] libsas: modify SATA error handler

Some more comments below. [..] + + pmp = sata_srst_pmp(link); + + msecs = 0; + now = jiffies; + if (time_after(deadline, now)) + msecs = jiffies_to_msecs(deadline - now); + + memset(tf, 0, sizeof(struct ata_taskfile)); + tf.ctl =

Re: [PATCH 1/3] libsas: modify SATA error handler

[ adding yuxia...@marvell.com ] On Tue, Jun 3, 2014 at 6:41 PM, Dan Williams dan.j.willi...@intel.com wrote: Hi, some notes below: On Thu, Apr 24, 2014 at 6:27 AM, Xiangliang Yu yxlr...@gmail.com wrote: Add support for SATA port softreset and port multiplier error handling. Some more

Re: [PATCH 1/3] libsas: modify SATA error handler

On Wed, Aug 6, 2014 at 3:50 AM, Xiangliang Yu yuxia...@marvell.com wrote: Hi, Dan James How about the patches about support for PM? Two months had passed since I submitted the patches. Thanks! Did you address my review comments? -- To unsubscribe from this list: send the line unsubscribe

Re: [PATCH 1/3] libsas: modify SATA error handler

On Tue, Jun 3, 2014 at 12:13 AM, Xiangliang Yu yuxia...@marvell.com wrote: Hi, How about the patch? I'll take a look today. Sorry for the latency. -- 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

Re: [PATCH 1/3] libsas: modify SATA error handler

Hi, some notes below: On Thu, Apr 24, 2014 at 6:27 AM, Xiangliang Yu yxlr...@gmail.com wrote: Add support for SATA port softreset and port multiplier error handling. Some more detailed notes about the approach and any caveats would be appreciated. Signed-off-by: Xiangliang Yu

Re: [PATCH 0/3] libsas: add support for port multiplier

On Fri, May 2, 2014 at 8:36 AM, Tejun Heo t...@kernel.org wrote: On Thu, Apr 24, 2014 at 09:27:03PM +0800, Xiangliang Yu wrote: This patch set will support SATA port multiplier(PM) in LIBSAS. LIBSAS is need to implement several key handling to support SATA PM: First,low level driver notify

Re: [PATCH RESEND] scsi_transport_sas: move bsg destructor into sas_rphy_remove

://marc.info/?t=13849746004 (patch + ACK + comments) http://marc.info/?t=13860945551 (gentoo, LSI repro) mpt2sas driver barfs when force removing a drive on 3.13.1 http://marc.info/?t=13912235131 Dan Williams had a few other suggestions for cleanup in this area, but those

Re: 3.2.57 regression: isci driver broken: Unable to reset I T nexus?

[ adding Ben ] On Mon, Apr 28, 2014 at 10:22 AM, Ondrej Zary li...@rainbow-software.org wrote: On Monday 28 April 2014 18:51:44 Jiang, Dave wrote: On Mon, 2014-04-28 at 16:28 +, Ondrej Zary wrote: On Monday 28 April 2014 17:50:29 Jiang, Dave wrote: On Mon, 2014-04-28 at 13:03 +0200,

Re: Please help me to review the patch about supporting SATA PM in LIBSAS

On Thu, Apr 17, 2014 at 9:03 AM, Dan Williams dan.j.willi...@intel.com wrote: On Wed, Apr 16, 2014 at 8:07 PM, xiangliang yu yxlr...@gmail.com wrote: hi, The patch is support SATA PM device and can find all devices that is attached to PM. Until now, i have tested the identified, hot-plug

  1   2   >