Re: [PATCH V3 0/4] genirq/affinity: irq vector spread among online CPUs as far as possible

Hi Artem, At 03/14/2018 11:29 AM, Dou Liyang wrote: Hi All, At 03/13/2018 05:35 PM, Rafael J. Wysocki wrote: On Tue, Mar 13, 2018 at 9:39 AM, Artem Bityutskiy wrote: On Tue, 2018-03-13 at 16:35 +0800, Ming Lei wrote: Then looks this issue need to fix by making possible

Re: [PATCH V3 0/4] genirq/affinity: irq vector spread among online CPUs as far as possible

Hi Rafael, Thank you so much for your reply. At 03/13/2018 05:25 PM, Rafael J. Wysocki wrote: On Tue, Mar 13, 2018 at 4:11 AM, Dou Liyang wrote: Hi Thomas, At 03/09/2018 11:08 PM, Thomas Gleixner wrote: [...] I'm not sure if there is a clear indicator whether

Re: [PATCH V3 0/4] genirq/affinity: irq vector spread among online CPUs as far as possible

Hi All, At 03/13/2018 05:35 PM, Rafael J. Wysocki wrote: On Tue, Mar 13, 2018 at 9:39 AM, Artem Bityutskiy wrote: On Tue, 2018-03-13 at 16:35 +0800, Ming Lei wrote: Then looks this issue need to fix by making possible CPU count accurate because there are other resources

Re: [PATCH v3] blk-throttle: fix race between blkcg_bio_issue_check() and cgroup_rmdir()

Fine, I will do the corresponding changes and post v5. Thanks, Joseph On 18/3/14 04:19, Tejun Heo wrote: > Hello, Joseph. > > On Mon, Mar 05, 2018 at 11:03:16PM +0800, Joseph Qi wrote: >> +static void blkg_pd_offline(struct blkcg_gq *blkg) >> +{ >> +int i; >> + >> +

Re: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory

On Tue, Mar 13, 2018 at 05:21:20PM -0600, Logan Gunthorpe wrote: > On 13/03/18 05:08 PM, Bjorn Helgaas wrote: > > On Tue, Mar 13, 2018 at 10:31:55PM +, Stephen Bates wrote: > > If it *is* necessary because Root Ports and devices below them behave > > differently than in conventional PCI, I

Re: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory

On 13/03/18 05:19 PM, Sinan Kaya wrote: > It is still a switch it can move packets but, maybe it can move data at > 100kbps speed. As Stephen pointed out, it's a requirement of the PCIe spec that a switch supports P2P. If you want to sell a switch that does P2P with bad performance then that's

Re: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory

On 13/03/18 05:08 PM, Bjorn Helgaas wrote: > On Tue, Mar 13, 2018 at 10:31:55PM +, Stephen Bates wrote: > If it *is* necessary because Root Ports and devices below them behave > differently than in conventional PCI, I think you should include a > reference to the relevant section of the

Re: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory

On 3/13/2018 6:48 PM, Logan Gunthorpe wrote: > > > On 13/03/18 04:29 PM, Sinan Kaya wrote: >> If hardware doesn't support it, blacklisting should have been the right >> path and I still think that you should remove all switch business from the >> code. >> I did not hear enough justification for

Re: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory

On Tue, Mar 13, 2018 at 10:31:55PM +, Stephen Bates wrote: > >> It sounds like you have very tight hardware expectations for this to work > >> at this moment. You also don't want to generalize this code for others and > >> address the shortcomings. > > No, that's the way the community has

Re: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory

On 13/03/18 04:29 PM, Sinan Kaya wrote: > If hardware doesn't support it, blacklisting should have been the right > path and I still think that you should remove all switch business from the > code. > I did not hear enough justification for having a switch requirement > for P2P. I disagree. >

Re: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory

Hi Sinan >If hardware doesn't support it, blacklisting should have been the right >path and I still think that you should remove all switch business from the > code. >I did not hear enough justification for having a switch requirement >for P2P. We disagree. As does the

Re: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory

>> It sounds like you have very tight hardware expectations for this to work >> at this moment. You also don't want to generalize this code for others and >> address the shortcomings. > No, that's the way the community has pushed this work Hi Sinan Thanks for all the input. As Logan has pointed

Re: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory

On 3/13/2018 6:00 PM, Logan Gunthorpe wrote: > > > On 13/03/18 03:22 PM, Sinan Kaya wrote: >> It sounds like you have very tight hardware expectations for this to work >> at this moment. You also don't want to generalize this code for others and >> address the shortcomings. > > No, that's the

Re: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory

On 13/03/18 03:22 PM, Sinan Kaya wrote: > It sounds like you have very tight hardware expectations for this to work > at this moment. You also don't want to generalize this code for others and > address the shortcomings. No, that's the way the community has pushed this work. Our original work

Re: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory

On 3/13/2018 4:46 PM, Logan Gunthorpe wrote: > > > On 13/03/18 01:53 PM, Sinan Kaya wrote: >> I agree disabling globally would be bad. Somebody can always say I have >> ten switches on my system. I want to do peer-to-peer on one switch only. Now, >> this change weakened security for the other

Re: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory

On 13/03/18 01:53 PM, Sinan Kaya wrote: > I agree disabling globally would be bad. Somebody can always say I have > ten switches on my system. I want to do peer-to-peer on one switch only. Now, > this change weakened security for the other switches that I had no intention > with doing P2P. > >

Re: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory

On 3/13/2018 3:19 PM, Logan Gunthorpe wrote: > > > On 13/03/18 01:10 PM, Sinan Kaya wrote: >> I was thinking of this for the pci_p2pdma_add_client() case for the >> parent pointer. >> >> +struct pci_p2pdma_client { >> +struct list_head list; >> +struct pci_dev *client; >> +struct

Re: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory

On 13/03/18 01:10 PM, Sinan Kaya wrote: > I was thinking of this for the pci_p2pdma_add_client() case for the > parent pointer. > > +struct pci_p2pdma_client { > + struct list_head list; > + struct pci_dev *client; > + struct pci_dev *provider; > +}; Yeah, that structure only

Re: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory

On 3/13/2018 2:44 PM, Logan Gunthorpe wrote: >> Do you think you can keep a pointer to the parent bridge instead of querying >> it >> via get_upstream_bridge_port() here so that we can reuse your >> pci_p2pdma_disable_acs() in the future. > > Keep a pointer where? pci_p2pdma_disable_acs() and

Re: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory

On 13/03/18 11:49 AM, Sinan Kaya wrote: And there's also the ACS problem which means if you want to use P2P on the root ports you'll have to disable ACS on the entire system. (Or preferably, the IOMMU groups need to get more sophisticated to allow for dynamic changes). Do you think you

Re: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory

On 12/03/18 09:28 PM, Sinan Kaya wrote: Maybe, dev parameter should also be struct pci_dev so that you can get rid of all to_pci_dev() calls in this code including find_parent_pci_dev() function. No, this was mentioned in v2. find_parent_pci_dev is necessary because the calling drivers

Re: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory

On 3/13/2018 12:43 PM, Logan Gunthorpe wrote: > > > On 12/03/18 09:28 PM, Sinan Kaya wrote: >> On 3/12/2018 3:35 PM, Logan Gunthorpe wrote: >> Regarding the switch business, It is amazing how much trouble you went into >> limit this functionality into very specific hardware. >> >> I thought that

Re: bsg-lib interface cleanup V2

On 3/13/18 9:28 AM, Christoph Hellwig wrote: > Hi all, > > this series cleans up various abuses of the bsg interfaces, and then > splits bsg for SCSI passthrough from bsg for arbitrary transport > passthrough. This removes the scsi_request abuse in bsg-lib that is > very confusing, and also

Re: [PATCH v2] block: bio_check_eod() needs to consider partition

On 3/13/18 9:25 AM, Bart Van Assche wrote: > On Tue, 2018-03-13 at 07:49 -0700, Jens Axboe wrote: >> On 3/13/18 2:18 AM, Christoph Hellwig wrote: >>> bio_check_eod() should check partiton size not the whole disk if >>> bio->bi_partno is non-zero. Does this by taking the call to bio_check_eod >>>

Re: disk-io lockup in 4.14.13 kernel

On Tue, 2018-03-13 at 19:16 +0200, Jaco Kroon wrote: > The server in question is the destination of numerous rsync/ssh cases > (used primarily for backups) and is not intended as a real-time system. > I'm happy to enable the options below that you would indicate would be > helpful in pinpointing

RE: [PATCH V5 2/5] scsi: megaraid_sas: fix selection of reply queue

> -Original Message- > From: Ming Lei [mailto:ming@redhat.com] > Sent: Tuesday, March 13, 2018 3:13 PM > To: James Bottomley; Jens Axboe; Martin K . Petersen > Cc: Christoph Hellwig; linux-s...@vger.kernel.org; linux- > bl...@vger.kernel.org; Meelis Roos; Don Brace; Kashyap Desai;

Re: [PATCH v3 01/11] PCI/P2PDMA: Support peer-to-peer memory

On 12/03/18 09:28 PM, Sinan Kaya wrote: On 3/12/2018 3:35 PM, Logan Gunthorpe wrote: Regarding the switch business, It is amazing how much trouble you went into limit this functionality into very specific hardware. I thought that we reached to an agreement that code would not impose any

Re: [PATCH v2] block: bio_check_eod() needs to consider partition

On Tue, Mar 13, 2018 at 04:25:40PM +, Bart Van Assche wrote: > On Tue, 2018-03-13 at 07:49 -0700, Jens Axboe wrote: > > On 3/13/18 2:18 AM, Christoph Hellwig wrote: > > > bio_check_eod() should check partiton size not the whole disk if > > > bio->bi_partno is non-zero. Does this by taking the

[PATCH 3/3] bsg: split handling of SCSI CDBs vs transport requeues

The current BSG design tries to shoe-horn the transport-specific passthrough commands into the overall framework for SCSI passthrough requests. This has a couple problems: - each passthrough queue has to set the QUEUE_FLAG_SCSI_PASSTHROUGH flag despite not dealing with SCSI commands at all.

[PATCH 2/3] bsg-lib: remove bsg_job.req

Users of the bsg-lib interface should only use the bsg_job data structure and not know about implementation details of it. Signed-off-by: Christoph Hellwig Reviewed-by: Benjamin Block Reviewed-by: Hannes Reinecke Reviewed-by: Johannes

[PATCH 1/3] bsg-lib: introduce a timeout field in struct bsg_job

The zfcp driver wants to know the timeout for a bsg job, so add a field to struct bsg_job for it in preparation of not exposing the request to the bsg-lib users. Signed-off-by: Christoph Hellwig Reviewed-by: Benjamin Block Reviewed-by: Hannes Reinecke

bsg-lib interface cleanup V2

Hi all, this series cleans up various abuses of the bsg interfaces, and then splits bsg for SCSI passthrough from bsg for arbitrary transport passthrough. This removes the scsi_request abuse in bsg-lib that is very confusing, and also makes sure we can sanity check the requests we get. The

Re: [PATCH v2] block: bio_check_eod() needs to consider partition

On Tue, 2018-03-13 at 07:49 -0700, Jens Axboe wrote: > On 3/13/18 2:18 AM, Christoph Hellwig wrote: > > bio_check_eod() should check partiton size not the whole disk if > > bio->bi_partno is non-zero. Does this by taking the call to bio_check_eod > > into blk_partition_remap. > > Applied,

Re: [PATCH 0/8] block: sed-opal: support write to shadow mbr

On Tue, Mar 13, 2018 at 02:08:53PM +0100, Jonas Rabenstein wrote: > Hi, > this patchset adds support to write data into the shadow mbr of sed-opal > enabled devices. They apply cleanly on today next-tree (next-20180313) > and requires the u64 short atom length fix from [0] as t

Re: [PATCH 8/8] block: sed-opal: ioctl for writing to shadow mbr

On Tue, Mar 13, 2018 at 02:09:01PM +0100, Jonas Rabenstein wrote: > Allow modification of the shadow mbr. If the shadow mbr is not marked as > done, this data will be presented read only as the device content. Only > after marking the shadow mbr as done and unlocking a locking range the > actual

Re: [PATCH 3/8] block: sed-opal: unify cmd start and finalize

On Tue, Mar 13, 2018 at 02:08:56PM +0100, Jonas Rabenstein wrote: > Every step starts with resetting the cmd buffer as well as the comid and > constructs the appropriate OPAL_CALL command. Consequently, those > actions may be combined into one generic function. > > Signed-off-by: Jonas Rabenstein

Re: disk-io lockup in 4.14.13 kernel

On Tue, 2018-03-13 at 16:59 +0200, Jaco Kroon wrote: > I quickly checked my dmesg logs and I'm not seeing that particular > message, could be that newer kernels only started warning about it? Hello Jaco, That message only appears if CONFIG_DEBUG_ATOMIC_SLEEP (sleep inside atomic) is enabled in

Re: disk-io lockup in 4.14.13 kernel

Hi Bart, On 13/03/2018 16:10, Bart Van Assche wrote: > On Tue, 2018-03-13 at 11:30 +0200, Jaco Kroon wrote: >> On 11/03/2018 07:00, Bart Van Assche wrote: >>> Did I see correctly that /dev/sdm is behind a MPT SAS controller? You may >>> want to contact the authors of this driver and Cc the

Re: [Possible REGRESSION, 4.16-rc4] Error updating SMART data during runtime and could not connect to lvmetad at some boot attempts

On Tue, 2018-03-13 at 22:32 +0800, Ming Lei wrote: > On Tue, Mar 13, 2018 at 02:08:23PM +0100, Martin Steigerwald wrote: > > Ming and Bart, I added you to cc, cause I had to do with you about another > > blk-mq report, please feel free to adapt. > > Looks RIP points to scsi_times_out+0x17/0x1d0,

Re: [PATCH v2] block: bio_check_eod() needs to consider partition

On 3/13/18 2:18 AM, Christoph Hellwig wrote: > bio_check_eod() should check partiton size not the whole disk if > bio->bi_partno is non-zero. Does this by taking the call to bio_check_eod > into blk_partition_remap. Applied, thanks. -- Jens Axboe

Re: [Possible REGRESSION, 4.16-rc4] Error updating SMART data during runtime and could not connect to lvmetad at some boot attempts

On Tue, Mar 13, 2018 at 02:08:23PM +0100, Martin Steigerwald wrote: > Hans de Goede - 11.03.18, 15:37: > > Hi Martin, > > > > On 11-03-18 09:20, Martin Steigerwald wrote: > > > Hello. > > > > > > Since 4.16-rc4 (upgraded from 4.15.2 which worked) I have an issue > > > with SMART checks

Re: disk-io lockup in 4.14.13 kernel

On Tue, 2018-03-13 at 11:30 +0200, Jaco Kroon wrote: > On 11/03/2018 07:00, Bart Van Assche wrote: > > Did I see correctly that /dev/sdm is behind a MPT SAS controller? You may > > want to contact the authors of this driver and Cc the linux-scsi mailing > > list. Sorry but I'm not familiar with

[PATCH 3/8] block: sed-opal: unify cmd start and finalize

Every step starts with resetting the cmd buffer as well as the comid and constructs the appropriate OPAL_CALL command. Consequently, those actions may be combined into one generic function. Signed-off-by: Jonas Rabenstein --- block/sed-opal.c | 243

[PATCH 2/8] block: sed-opal: unify space check in add_token_*

All add_token_* functions have a common set of conditions that have to be checked. Use a common function for those checks in order to avoid different behaviour. Signed-off-by: Jonas Rabenstein --- block/sed-opal.c | 25 - 1 file

[PATCH 5/8] block: sed-opal: print failed function address

add function address (and if available its symbol) to the message if a step function fails. Signed-off-by: Jonas Rabenstein --- block/sed-opal.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/block/sed-opal.c b/block/sed-opal.c

[PATCH 4/8] block: sed-opal: unify error handling of responses

Also response_get_token had already been in place, its functionality had been duplicated within response_get_{u64,bytestring} with the same error handling. Unify the handling by reusing response_get_token within the other functions. Signed-off-by: Jonas Rabenstein

[PATCH 7/8] block: sed-opal: add ioctl for done-mark of shadow mbr

Enable users to mark the shadow mbr as done without completely deactivating the shadow mbr feature. This may be useful on reboots, when the power to the disk is not disconnected in between and the shadow mbr stores the required boot files. Of course, this saves also the (few) commands required to

[PATCH 8/8] block: sed-opal: ioctl for writing to shadow mbr

Allow modification of the shadow mbr. If the shadow mbr is not marked as done, this data will be presented read only as the device content. Only after marking the shadow mbr as done and unlocking a locking range the actual content is accessible. Signed-off-by: Jonas Rabenstein

[PATCH 6/8] block: sed-opal: split generation of bytestring header and content

Split the header generation from the (normal) memcpy part if a bytestring is copied into the command buffer. This allows in-place generation of the bytestring content. For example, copy_from_user may be used without an intermediate buffer. Signed-off-by: Jonas Rabenstein

[PATCH 1/8] block: sed-opal: use correct macro for method length

also the values of OPAL_UID_LENGTH and OPAL_METHOD_LENGTH are the same, it is weird to use OPAL_UID_LENGTH for the definition of the methods. Signed-off-by: Jonas Rabenstein --- block/sed-opal.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH 0/8] block: sed-opal: support write to shadow mbr

Hi, this patchset adds support to write data into the shadow mbr of sed-opal enabled devices. They apply cleanly on today next-tree (next-20180313) and requires the u64 short atom length fix from [0] as that is still missing in that tree. As I only can test on my only sed-opal enabled Samsung 850

Re: [Possible REGRESSION, 4.16-rc4] Error updating SMART data during runtime and could not connect to lvmetad at some boot attempts

Hans de Goede - 11.03.18, 15:37: > Hi Martin, > > On 11-03-18 09:20, Martin Steigerwald wrote: > > Hello. > > > > Since 4.16-rc4 (upgraded from 4.15.2 which worked) I have an issue > > with SMART checks occassionally failing like this: > > > > smartd[28017]: Device: /dev/sdb [SAT], is in SLEEP

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

From: Stephen Kitt > Sent: 09 March 2018 22:34 > > COMMAND_SIZE currently uses an array of values in block/scsi_ioctl.c. > A number of device_handler functions use this to initialise arrays, > and this is flagged by -Wvla. > > This patch replaces COMMAND_SIZE with a variant using a formula which

[PATCH V5 4/5] scsi: virtio_scsi: fix IO hang caused by irq vector automatic affinity

Now 84676c1f21e8ff5(genirq/affinity: assign vectors to all possible CPUs) has been merged to V4.16-rc, and it is easy to allocate all offline CPUs for some irq vectors, this can't be avoided even though the allocation is improved. For example, on a 8cores VM, 4~7 are not-present/offline, 4 queues

[PATCH V5 2/5] scsi: megaraid_sas: fix selection of reply queue

>From 84676c1f21 (genirq/affinity: assign vectors to all possible CPUs), one msix vector can be created without any online CPU mapped, then command may be queued, and won't be notified after its completion. This patch setups mapping between cpu and reply queue according to irq affinity info

[PATCH V5 5/5] scsi: virtio_scsi: unify scsi_host_template

Now we switch to use_blk_mq always, and both single queue and multi queue cases can be handled in one .queuecommand callback, not necessary to use two scsi_host_template. Suggested-by: Christoph Hellwig , Cc: Omar Sandoval , Cc: "Martin K. Petersen"

[PATCH V5 3/5] scsi: introduce force_blk_mq

>From scsi driver view, it is a bit troublesome to support both blk-mq and non-blk-mq at the same time, especially when drivers need to support multi hw-queue. This patch introduces 'force_blk_mq' to scsi_host_template so that drivers can provide blk-mq only support, so driver code can avoid the

[PATCH V5 1/5] scsi: hpsa: fix selection of reply queue

>From 84676c1f21 (genirq/affinity: assign vectors to all possible CPUs), one msix vector can be created without any online CPU mapped, then one command's completion may not be notified. This patch setups mapping between cpu and reply queue according to irq affinity info retrived by

[PATCH V5 0/5] SCSI: fix selection of reply(hw) queue

Hi All, The patches fixes reply queue(virt-queue on virtio-scsi) selection on hpsa, megaraid_sa and virtio-scsi, and IO hang can be caused easily by this issue. This issue is triggered by 84676c1f21e8 ("genirq/affinity: assign vectors to all possible CPUs"). After 84676c1f21e8, it is easy to see

Re: disk-io lockup in 4.14.13 kernel

Hi Bart, On 11/03/2018 07:00, Bart Van Assche wrote: > On Sun, 2018-03-11 at 06:33 +0200, Jaco Kroon wrote: >> crowsnest ~ # find /sys -name sdm >> /sys/kernel/debug/block/sdm >>

Re: [PATCH V3 0/4] genirq/affinity: irq vector spread among online CPUs as far as possible

On Tue, Mar 13, 2018 at 4:11 AM, Dou Liyang wrote: > Hi Thomas, > > At 03/09/2018 11:08 PM, Thomas Gleixner wrote: > [...] >> >> >> I'm not sure if there is a clear indicator whether physcial hotplug is >> supported or not, but the ACPI folks (x86) and architecture

[PATCH v2] block: bio_check_eod() needs to consider partition

bio_check_eod() should check partiton size not the whole disk if bio->bi_partno is non-zero. Does this by taking the call to bio_check_eod into blk_partition_remap. Based on an earlier patch from Jiufei Xue. Fixes: 74d46992e0d9 ("block: replace bi_bdev with a gendisk pointer and partitions

Re: [PATCH V3 0/4] genirq/affinity: irq vector spread among online CPUs as far as possible

On Tue, 2018-03-13 at 16:35 +0800, Ming Lei wrote: > Then looks this issue need to fix by making possible CPU count > accurate > because there are other resources allocated according to > num_possible_cpus(), > such as percpu variables. Short term the regression should be fixed. It is already

Re: [PATCH V3 0/4] genirq/affinity: irq vector spread among online CPUs as far as possible

On Tue, Mar 13, 2018 at 09:38:41AM +0200, Artem Bityutskiy wrote: > On Tue, 2018-03-13 at 11:11 +0800, Dou Liyang wrote: > > I also > > met the situation that BIOS told to ACPI that it could support > > physical > > CPUs hotplug, But actually, there was no hardware slots in the > > machine. > >

Re: [PATCH] block: bio_check_eod() needs to consider partition

On Thu, Mar 08, 2018 at 02:09:23PM -0700, Jens Axboe wrote: > On Thu, Mar 08 2018, Christoph Hellwig wrote: > > bio_check_eod() should check partiton size not the whole disk if > > bio->bi_partno is non-zero. > > > > Based on an earlier patch from Jiufei Xue. > > This doesn't apply, what did you