erlain
> 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
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
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
>> >> you
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:
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 devices attached with
8
> [] 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(). libata will handle
> ata qcs cor
8
> [] 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(). libata will handle
> ata qcs cor
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 task is freed, but
>> ata qc
On Thu, Jan 18, 2018 at 5:18 AM, Will Deacon 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
>> wrote:
>> > On Thu, Jan 11, 2018 at 4:46 PM, Dan Williams
>&
On Thu, Jan 11, 2018 at 5:19 PM, James Bottomley
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
>> '
On Thu, Jan 11, 2018 at 5:19 PM, Linus Torvalds
wrote:
> On Thu, Jan 11, 2018 at 4:46 PM, Dan Williams
> wrote:
>>
>> This series incorporates Mark Rutland's latest ARM changes and adds
>> the x86 specific implementation of 'ifence_array_ptr'. That ifence
git branch
here:
git://git.kernel.org/pub/scm/linux/kernel/git/djbw/linux nospec-v2
Note that the BPF fix for Spectre variant1 is merged in the bpf.git
tree [4], and is not included in this branch.
[2]:
https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memor
l patch by Elena Reshetova.
Cc: qla2xxx-upstr...@qlogic.com
Cc: "James E.J. Bottomley"
Cc: "Martin K. Petersen"
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Elena Reshetova
Signed-off-by: Dan Williams
---
drivers/scsi/qla2xxx/qla_mr.c | 17 +++--
1 file chan
On Sat, Jan 6, 2018 at 1:03 AM, Greg KH 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
On Thu, Jan 11, 2018 at 1:54 AM, Jiri Kosina 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 wrote:
>> > > On Fri, 5 Jan 2018, Dan William
On Tue, Jan 9, 2018 at 11:34 AM, Jiri Kosina wrote:
> On Fri, 5 Jan 2018, Dan Williams wrote:
>
> [ ... snip ... ]
>> Andi Kleen (1):
>> x86, barrier: stop speculation for failed access_ok
>>
>> Dan Williams (13):
>> x86: implement nospec_barri
On Sat, Jan 6, 2018 at 11:37 AM, Dan Williams wrote:
> On Fri, Jan 5, 2018 at 5:09 PM, Dan Williams wrote:
>> Quoting Mark's original RFC:
>>
>> "Recently, Google Project Zero discovered several classes of attack
>> against speculative execution. One
On Fri, Jan 5, 2018 at 5:09 PM, Dan Williams 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 bounds checks to be bypassed und
On Fri, Jan 5, 2018 at 6:22 PM, Eric W. Biederman wrote:
> Dan Williams writes:
>
>> Quoting Mark's original RFC:
>>
>> "Recently, Google Project Zero discovered several classes of attack
>> against speculative execution. One of these, known as variant-1
x86, barrier: stop speculation 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
t;
Cc: linux-scsi@vger.kernel.org
Signed-off-by: Elena Reshetova
Signed-off-by: Dan Williams
---
drivers/scsi/qla2xxx/qla_mr.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_mr.c b/drivers/scsi/qla2xxx/qla_mr.c
index d5da3981cefe..1
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
>
> shost->work_q
> new work[PORTE_BY
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
>>> persistence (or not).
>>>
>>
>>
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 (or not).
>
Why persist
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 Dan pointed out.
>>>
>
On Wed, Apr 19, 2017 at 11:41 AM, Logan Gunthorpe 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_pagemap directly.
>
On Wed, Apr 19, 2017 at 11:19 AM, Logan Gunthorpe 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
>>> to pass
On Wed, Apr 19, 2017 at 10:32 AM, Jerome Glisse 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 wrote:
>> >
>> >
>> > On 19/04/17 09:55 AM, Jason Gunthorpe wrote:
>> >> I wa
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 to the dev_pagemap str
On Tue, Apr 18, 2017 at 3:56 PM, Logan Gunthorpe wrote:
>
>
> On 18/04/17 04:50 PM, Dan Williams wrote:
>> On Tue, Apr 18, 2017 at 3:48 PM, Logan Gunthorpe wrote:
>>>
>>>
>>> On 18/04/17 04:28 PM, Dan Williams wrote:
>>>> Unlike the pci b
On Tue, Apr 18, 2017 at 3:46 PM, Benjamin Herrenschmidt
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 user space, and would like
On Tue, Apr 18, 2017 at 3:42 PM, Jason Gunthorpe
wrote:
> On Tue, Apr 18, 2017 at 03:28:17PM -0700, Dan Williams wrote:
>
>> Unlike the pci bus address offset case which I think is fundamental to
>> support since shipping archs do this toda
>
> But we can support this b
On Tue, Apr 18, 2017 at 3:48 PM, Logan Gunthorpe 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 to say
>> p2p is restricte
On Tue, Apr 18, 2017 at 3:15 PM, Logan Gunthorpe wrote:
>
>
> On 18/04/17 03:36 PM, Dan Williams wrote:
>> On Tue, Apr 18, 2017 at 2:22 PM, Jason Gunthorpe
>> wrote:
>>> On Tue, Apr 18, 2017 at 02:11:33PM -0700, Dan Williams wrote:
>>>>> I
On Tue, Apr 18, 2017 at 2:22 PM, Jason Gunthorpe
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 when the target page is
>> back
On Tue, Apr 18, 2017 at 2:03 PM, Jason Gunthorpe
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 need to be modified to either support p2p
&g
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
>> >> the special hardware that ops is control
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 the check down there in
On Tue, Apr 18, 2017 at 11:00 AM, Jason Gunthorpe
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 memory to user space, and would like
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 drivers to do it for
>> GPUs behind a
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 instantiate the necessary str
On Sat, Apr 15, 2017 at 8:01 PM, Benjamin Herrenschmidt
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 that switch
>> device obje
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 so that iomem pages do
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 ?
>
> Not at this time. We
would 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
> Fixes: 08024885a2a3 ("ses: Add power_status to SES device slot")
Reviewed-by: Dan Williams
On Wed, Apr 5, 2017 at 6:13 AM, Mauricio Faria de Oliveira
wrote:
> Hi Dan,
>
> Thanks for reviewing.
>
> On 04/04/2017 06:07 PM, Dan Williams wrote:
>>>
>>> @@ -594,6 +594,10 @@ static ssize_t get_component_power_status(struct
>>> device *cdev,
>
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 available to get the power status of
On Mon, Apr 3, 2017 at 4:12 PM, Logan Gunthorpe 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()
>> conversion will sti
On Mon, Apr 3, 2017 at 3:10 PM, Logan Gunthorpe wrote:
>
>
> On 03/04/17 03:44 PM, Dan Williams wrote:
>> On Mon, Apr 3, 2017 at 2:20 PM, Logan Gunthorpe wrote:
>>> Hi Christoph,
>>>
>>> What are your thoughts on an approach like the following untes
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 attempt to access
> i
.info/?l=linux-block&m=148554717109098&w=2
>
> Signed-off-by: Jan Kara
Acked-by: Dan Williams
On Wed, Feb 8, 2017 at 4:08 PM, James Bottomley
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 like this.
>
> Looking at the config
On Mon, Feb 6, 2017 at 8:09 PM, 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 wrote:
>>>> Dan,
>>>>
>>>&g
On Wed, Feb 1, 2017 at 2:35 PM, Jens Axboe wrote:
> On 02/01/2017 02:05 PM, Dan Williams wrote:
>> Warnings of the following form occur because scsi reuses a devt number
>> while the block layer still has it referenced as the name of the bdi
>> [1]:
>>
>> WA
o/?l=linux-scsi&m=147116857810716&w=4
[2]: http://marc.info/?l=linux-block&m=148554717109098&w=2
Cc: James Bottomley
Cc: Bart Van Assche
Cc: "Martin K. Petersen"
Cc: Christoph Hellwig
Cc: Jens Axboe
Cc: Jan Kara
Reported-by: Omar Sandoval
Tested-by: Omar Sandoval
Sign
o/?l=linux-scsi&m=147116857810716&w=4
[2]: http://marc.info/?l=linux-block&m=148554717109098&w=2
Cc: James Bottomley
Cc: Bart Van Assche
Cc: "Martin K. Petersen"
Cc: Christoph Hellwig
Cc: Jens Axboe
Cc: Jan Kara
Reported-by: Omar Sandoval
Signed-off-by: Dan Williams
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 drivers or oth
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
>
> Also I think you
On Sun, Jan 29, 2017 at 11:22 PM, Omar Sandoval wrote:
> On Mon, Jan 30, 2017 at 08:05:52AM +0100, Hannes Reinecke wrote:
>> On 01/29/2017 05:58 AM, Dan Williams wrote:
>> > Warnings of the following form occur because scsi reuses a devt number
>> > while the block la
o/?l=linux-scsi&m=147116857810716&w=4
[2]: http://marc.info/?l=linux-block&m=148554717109098&w=2
Cc: James Bottomley
Cc: Bart Van Assche
Cc: "Martin K. Petersen"
Cc: Christoph Hellwig
Cc: Jens Axboe
Reported-by: Omar Sandoval
Signed-off-by: Dan Williams
---
block/blk-
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 noisy, warning.
>>>
On Fri, Nov 18, 2016 at 1:00 AM, John Garry wrote:
> On 18/11/2016 01:53, Dan Williams wrote:
>>
>> On Thu, Nov 17, 2016 at 7:23 AM, John Garry wrote:
>>>
>>> On 11/11/2016 08:49, wangyijing wrote:
>>>>>>>
>>>>>>&g
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
> queue the events; there
On Wed, Nov 9, 2016 at 11:09 AM, Dan Williams wrote:
> 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 annoy
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 domain rediscovery competin
On Thu, Oct 13, 2016 at 1:24 PM, Jens Axboe wrote:
> On 10/13/2016 02:19 PM, Dan Williams wrote:
>>
>> On Thu, Oct 13, 2016 at 1:09 PM, Jens Axboe wrote:
>>>
>>> On 10/13/2016 02:06 PM, Dan Williams wrote:
>>>>
>>>>
>>&
On Thu, Oct 13, 2016 at 1:09 PM, Jens Axboe wrote:
> On 10/13/2016 02:06 PM, Dan Williams wrote:
>>
>> On Thu, Oct 13, 2016 at 12:53 PM, Adam Manzanares
>> wrote:
>>>
>>> Patch adds an association between iocontext ioprio and the ioprio of a
>>&g
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 then the
> iopriority of the
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 @@ static void sd_probe_asyn
[ adding Bart back to the cc ]
On Sun, Aug 14, 2016 at 11:08 AM, Dan Williams wrote:
> On Sun, Aug 14, 2016 at 10:20 AM, James Bottomley
> wrote:
[..]
> I like it. I still think the bdi registration code should be in
> charge of taking the extra reference on the disk device
On Sun, Aug 14, 2016 at 10:20 AM, James Bottomley
wrote:
> On Sat, 2016-08-13 at 11:27 -0700, Dan Williams wrote:
>> On Sat, Aug 13, 2016 at 10:43 AM, James Bottomley
>> wrote:
>> > On Sat, 2016-08-13 at 09:29 -0700, Dan Williams wrote:
>> > > On Sat, Aug
On Sat, Aug 13, 2016 at 10:43 AM, James Bottomley
wrote:
> On Sat, 2016-08-13 at 09:29 -0700, Dan Williams wrote:
>> On Sat, Aug 13, 2016 at 8:23 AM, James Bottomley
>> wrote:
>> > It does? The race is the fact that the parent can be removed
>> > before the ch
On Sat, Aug 13, 2016 at 11:27 AM, Dan Williams 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 level.
>
> You're
On Sat, Aug 13, 2016 at 8:23 AM, James Bottomley
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 12, 2016 at 5:17 PM, James Bottomley
>> &g
On Fri, Aug 12, 2016 at 5:29 PM, Dan Williams wrote:
> On Fri, Aug 12, 2016 at 5:17 PM, James Bottomley
> 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
On Fri, Aug 12, 2016 at 5:17 PM, James Bottomley
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 registered, is it rather time to
>> complete the convers
On Fri, Aug 12, 2016 at 2:35 PM, Bart Van Assche
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 following fix for a crash that was triggered
...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
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> Martin, can you please confirm whether the above is
On Tue, May 31, 2016 at 8:21 PM, Dan Williams wrote:
> On Tue, May 31, 2016 at 1:38 AM, Wei Fang wrote:
>> sas_ata_strategy_handler() adds the works of the ata error handler
>> to system_unbound_wq. This workqueue asynchronously runs work items,
>> so the ata error hand
#x27;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
> Signed-off-by: Wei Fang
Acked-by: Dan Willia
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 majord
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)
>> > > > +{
>> > > [...]
>> > > > +#define DO_DEB
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.
>>
>> -Jeff
>
> Not sure I follow? I
On Wed, Nov 4, 2015 at 2:44 PM, James Bottomley
wrote:
[..]
> The fundamental problem with this is how have the conditions that caused
> us to move away from list restart:
>
> commit bc3f02a795d3b4faa99d37390174be2a75d091bd
> Author: Dan Williams
> Date: Tue Aug 28 2
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
>> documented in patch
he most straightforward solution seems to be to invert the ordering of
> the set_current_state and kthread_should_stop.
>
> The issue has been noticed during reboot test on a 3.0 based kernel but
> the current code seems to be affected in the same way.
>
> Cc: stable # 3.6+
> R
On Mon, Jul 27, 2015 at 11:38 AM, James Bottomley
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() returns.
> Destroying the subtree is lef
On Mon, Jul 27, 2015 at 11:07 AM, James Bottomley
wrote:
> On Mon, 2015-07-27 at 08:48 -0700, Dan Williams wrote:
>> On Mon, Jul 27, 2015 at 8:17 AM, James Bottomley
>> wrote:
>> > On Wed, 2015-07-22 at 14:08 -0700, Dan Williams wrote:
>> >> I don't
On Mon, Jul 27, 2015 at 10:11 AM, James Bottomley
wrote:
> On Mon, 2015-07-27 at 08:48 -0700, Dan Williams wrote:
>> On Mon, Jul 27, 2015 at 8:17 AM, James Bottomley
>> wrote:
>> > On Wed, 2015-07-22 at 14:08 -0700, Dan Williams wrote:
>> >> On Wed, Jul 2
On Mon, Jul 27, 2015 at 8:17 AM, James Bottomley
wrote:
> On Wed, 2015-07-22 at 14:08 -0700, Dan Williams wrote:
>> On Wed, Jul 22, 2015 at 11:28 AM, James Bottomley
>> wrote:
>> >
>> >> }
>> >>
>> >> void sas_device_set_phy(struct d
On Wed, Jul 22, 2015 at 11:28 AM, James Bottomley
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
he devices from rphy down before deleting the parent port.
Cc:
Reported-by: Praveen Murali
Tested-by: Praveen Murali
Reviewed-by: Hannes Reinecke
Signed-off-by: Dan Williams
---
Hi Andrew,
Can you take this through -mm. It's been on linux-scsi for a couple
months, and Hanne
he devices from rphy down before deleting the parent port.
Cc:
Reported-by: Praveen Murali
Tested-by: Praveen Murali
Signed-off-by: Dan Williams
---
drivers/scsi/libsas/sas_discover.c |6 +++---
drivers/scsi/libsas/sas_port.c |1 -
2 files changed, 3 insertions(+), 4 deletio
this problem. Libsas should delete
all the devices from rphy down before deleting the parent port.
Cc:
Reported-by: Praveen Murali
Tested-by: Praveen Murali
Signed-off-by: Dan Williams
---
v2: drop the "---" separators that will confuse git-am. Thanks Luis!
drivers/scsi/
s now exposes this problem. Libsas should delete
all the devices from rphy down before deleting the parent port.
Cc:
Reported-by: Praveen Murali
Tested-by: Praveen Murali
Signed-off-by: Dan Williams
---
drivers/scsi/libsas/sas_discover.c |6 +++---
drivers/scsi/libsas/sas_port.c |1
ter optimizations for scsi-mq
> in the future.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Dan Williams
--
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 Tue, Nov 4, 2014 at 10:58 AM, Christoph Hellwig 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.
>
> If there's
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))
[ adding yuxia...@marvell.com ]
On Tue, Jun 3, 2014 at 6:41 PM, Dan Williams wrote:
> Hi, some notes below:
>
> On Thu, Apr 24, 2014 at 6:27 AM, Xiangliang Yu wrote:
>> Add support for SATA port softreset and port multiplier error
>> handling.
>
> Some more detailed n
1 - 100 of 201 matches
Mail list logo
