Re: [PATCH v3] dm: don't allow ioctls to targets that don't map to whole devices

On Fri, 2017-02-03 at 19:17 +0100, Johannes Thumshirn wrote: > Forgotten git add? git commit --amend without git add is such a classic > mistake on my side as well :-/ Are you familiar with the -a option of git commit? Just run git commit -a --amend Bart.

[PATCH] nbd: handle single path failures gracefully

Currently if we have multiple connections and one of them goes down we will tear down the whole device. However there's no reason we need to do this as we could have other connections that are working fine. Deal with this by keeping track of the state of the different connections, and if we lose

[PATCH] blk-mq-sched: separate mark hctx and queue restart operations

From: Omar Sandoval In blk_mq_sched_dispatch_requests(), we call blk_mq_sched_mark_restart() after we dispatch requests left over on our hardware queue dispatch list. This is so we'll go back and dispatch requests from the scheduler. In this case, it's only necessary to restart

Re: [PATCH v3] dm: don't allow ioctls to targets that don't map to whole devices

On 02/03/2017 05:41 PM, Christoph Hellwig wrote: On Fri, Feb 03, 2017 at 11:39:22AM -0500, Mike Snitzer wrote: I assume you meant for v3 to remove the newline? ;) I did. And I swear I did edit the file, but I guess the ammend didn't work. I guess it's time for the weekend.. I'll resend

Re: [PATCH 04/24] fs: Provide infrastructure for dynamic BDIs in filesystems

On Fri, Feb 03, 2017 at 02:50:42PM +0100, Jan Kara wrote: > On Thu 02-02-17 11:28:27, Liu Bo wrote: > > Hi, > > > > On Thu, Feb 02, 2017 at 06:34:02PM +0100, Jan Kara wrote: > > > Provide helper functions for setting up dynamically allocated > > > backing_dev_info structures for filesystems and

Re: [PATCH 3/6] genirq/affinity: update CPU affinity for CPU hotplug events

Hi Christoph, [auto build test ERROR on block/for-next] [also build test ERROR on v4.10-rc6] [cannot apply to next-20170203] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Christoph-Hellwig

Re: [PATCH 08/24] btrfs: Convert to separately allocated bdi

On Thu, Feb 02, 2017 at 06:34:06PM +0100, Jan Kara wrote: > Allocate struct backing_dev_info separately instead of embedding it > inside superblock. This unifies handling of bdi among users. Looks good. Reviewed-by: Liu Bo Thanks, -liubo > > CC: Chris Mason

Re: [REGRESSION v4.10-rc1] blkdev_issue_zeroout() returns -EREMOTEIO on the first call for SCSI device that doesn't support WRITE SAME

> "Jens" == Jens Axboe writes: >> I think we should fix sd.c to only send WRITE SAME if either of the >> variants are explicitly listed as supported through REPORT SUPPORTED >> OPERATION CODES, or maybe through a whitelist if there are important >> enough devices. Jens> Yep

Re: [PATCH] blk-mq-sched: separate mark hctx and queue restart operations

On Fri, Feb 03, 2017 at 11:35:58AM -0800, Omar Sandoval wrote: > From: Omar Sandoval > > In blk_mq_sched_dispatch_requests(), we call blk_mq_sched_mark_restart() > after we dispatch requests left over on our hardware queue dispatch > list. This is so we'll go back and dispatch

[PATCH RESEND] blkcg: fix double free of new_blkg in blkcg_init_queue

If blkg_create fails, new_blkg passed as an argument will be freed by blkg_create, so there is no need to free it again. Signed-off-by: Hou Tao --- block/blk-cgroup.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/block/blk-cgroup.c

Re: [PATCH 5/9] virtio: allow drivers to request IRQ affinity when creating VQs

On 2017年01月27日 16:16, Christoph Hellwig wrote: Add a struct irq_affinity pointer to the find_vqs methods, which if set is used to tell the PCI layer to create the MSI-X vectors for our I/O virtqueues with the proper affinity from the start. Compared to after the fact affinity hints this gives

Re: [PATCH 1/9] virtio_pci: remove struct virtio_pci_vq_info

On Fri, Feb 03, 2017 at 03:54:36PM +0800, Jason Wang wrote: >> +list_for_each_entry(vq, _dev->vdev.vqs, list) { >> +if (vq->callback && vring_interrupt(irq, vq) == IRQ_HANDLED) > > The check of vq->callback seems redundant, we will check it soon in > vring_interrupt(). Good point

Re: [PATCH 2/9] virtio_pci: use shared interrupts for virtqueues

On Fri, Feb 03, 2017 at 03:54:54PM +0800, Jason Wang wrote: > On 2017年01月27日 16:16, Christoph Hellwig wrote: >> +snprintf(vp_dev->msix_names[i + 1], >> + sizeof(*vp_dev->msix_names), "%s-%s", >> dev_name(_dev->vdev.dev), names[i]); >>

Re: [REGRESSION v4.10-rc1] blkdev_issue_zeroout() returns -EREMOTEIO on the first call for SCSI device that doesn't support WRITE SAME

On 02/03/2017 03:45 PM, Martin K. Petersen wrote: >> "Jens" == Jens Axboe writes: > >>> I think we should fix sd.c to only send WRITE SAME if either of the >>> variants are explicitly listed as supported through REPORT SUPPORTED >>> OPERATION CODES, or maybe through a

Re: [PATCH 6/9] virtio: provide a method to get the IRQ affinity mask for a virtqueue

On 2017年01月27日 16:16, Christoph Hellwig wrote: This basically passed up the pci_irq_get_affinity information through virtio through an optional get_vq_affinity method. It is only implemented by the PCI backend for now, and only when we use per-virtqueue IRQs. Signed-off-by: Christoph Hellwig

RE: [PATCH] genhd: Do not hold event lock when scheduling workqueue elements

the patch description, namely that > > disk_block_events() calls are no longer serialized. Are you sure it is safe > > to drop the serialization of disk_block_events() calls? > > > Well, this whole synchronization stuff it a bit weird; I so totally fail > to see the rationale for it.

Re: [PATCH 2/9] virtio_pci: use shared interrupts for virtqueues

On Fri, Feb 03, 2017 at 05:47:41PM +0800, Jason Wang wrote: >> No, we need to allocate the array larger in that case as want proper >> names for the interrupts. > > Consider the case of !per_vq_vectors, the size of msix_names is 2, but > snprintf can do out of bound accessing here. (We name the

Re: [PATCH] dm: don't allow ioctls to targets that don't map to whole devices

On 02/03/2017 11:06 AM, Christoph Hellwig wrote: .. at least for unprivilegued users. Before we called into the SCSI ioctl code to allow excemptions for a few SCSI passthrough ioctls, but this is pretty unsafe and except for this call dm knows nothing about SCSI ioctls. As SCSI the SCSI ioctl

Re: [PATCH] dm: don't allow ioctls to targets that don't map to whole devices

On Fri, Feb 03, 2017 at 11:10:10AM +0100, Johannes Thumshirn wrote: > On 02/03/2017 11:06 AM, Christoph Hellwig wrote: >> .. at least for unprivilegued users. Before we called into the SCSI >> ioctl code to allow excemptions for a few SCSI passthrough ioctls, >> but this is pretty unsafe and

Re: [PATCH RESEND] blkcg: fix double free of new_blkg in blkcg_init_queue

On 02/03/2017 02:19 AM, Hou Tao wrote: > If blkg_create fails, new_blkg passed as an argument will > be freed by blkg_create, so there is no need to free it again. Thanks, looks good to me. Applied. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the

Re: [REGRESSION v4.10-rc1] blkdev_issue_zeroout() returns -EREMOTEIO on the first call for SCSI device that doesn't support WRITE SAME

On 02/03/2017 12:55 AM, Junichi Nomura wrote: > I found following ext4 error occurs on a certain storage since v4.10-rc1: > EXT4-fs (sdc1): Delayed block allocation failed for inode 12 at logical > offset 100 with max blocks 2 with error 121 > EXT4-fs (sdc1): This should not happen!! Data

[PATCH 2/6] genirq/affinity: assign vectors to all present CPUs

Currently we only assign spread vectors to online CPUs, which ties the IRQ mapping to the currently online devices and doesn't deal nicely with the fact that CPUs could come and go rapidly due to e.g. power management. Instead assign vectors to all present CPUs to avoid this churn.

[PATCH 3/6] genirq/affinity: update CPU affinity for CPU hotplug events

Remove a CPU from the affinity mask when it goes offline and add it back when it returns. In case the vetor was assigned only to the CPU going offline it will be shutdown and re-started when the CPU reappears. Signed-off-by: Christoph Hellwig --- arch/x86/kernel/irq.c | 3

[PATCH 6/6] nvme: allocate queues for all possible CPUs

Unlike most drіvers that simply pass the maximum possible vectors to pci_alloc_irq_vectors NVMe needs to configure the device before allocting the vectors, so it needs a manual update for the new scheme of using all present CPUs. Signed-off-by: Christoph Hellwig ---

Re: [PATCH 22/24] ubifs: Convert to separately allocated bdi

On Thu 02-02-17 21:34:32, Richard Weinberger wrote: > Jan, > > Am 02.02.2017 um 18:34 schrieb Jan Kara: > > Allocate struct backing_dev_info separately instead of embedding it > > inside the superblock. This unifies handling of bdi among users. > > > > CC: Richard Weinberger > >

Re: [PATCH 04/24] fs: Provide infrastructure for dynamic BDIs in filesystems

On Thu 02-02-17 11:28:27, Liu Bo wrote: > Hi, > > On Thu, Feb 02, 2017 at 06:34:02PM +0100, Jan Kara wrote: > > Provide helper functions for setting up dynamically allocated > > backing_dev_info structures for filesystems and cleaning them up on > > superblock destruction. > > Just one concern,

Re: dm: don't allow ioctls to targets that don't map to whole devices

On Fri, Feb 03 2017 at 5:06am -0500, Christoph Hellwig wrote: > .. at least for unprivilegued users. Before we called into the SCSI > ioctl code to allow excemptions for a few SCSI passthrough ioctls, > but this is pretty unsafe and except for this call dm knows nothing > about

spread MSI(-X) vectors to all possible CPUs

Hi all, this series changes our automatic MSI-X vector assignment so that it takes all present CPUs into account instead of all online ones. This allows to better deal with cpu hotplug events, which could happen frequently due to power management for example. -- To unsubscribe from this list:

[PATCH 4/6] blk-mq: include all present CPUs in the default queue mapping

This way we get a nice distribution independent of the current cpu online / offline state. Signed-off-by: Christoph Hellwig --- block/blk-mq-cpumap.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/block/blk-mq-cpumap.c b/block/blk-mq-cpumap.c index

Re: [REGRESSION v4.10-rc1] blkdev_issue_zeroout() returns -EREMOTEIO on the first call for SCSI device that doesn't support WRITE SAME

On Fri, Feb 03, 2017 at 08:21:31AM -0700, Jens Axboe wrote: > > Error 121 (EREMOTEIO) was returned from blkdev_issue_zeroout(). > > That came from sd driver because WRITE SAME was sent to the device > > which didn't support it. > > > > The problem was introduced by commit e73c23ff736e ("block:

Re: [REGRESSION v4.10-rc1] blkdev_issue_zeroout() returns -EREMOTEIO on the first call for SCSI device that doesn't support WRITE SAME

On 02/03/2017 09:12 AM, Christoph Hellwig wrote: > On Fri, Feb 03, 2017 at 08:21:31AM -0700, Jens Axboe wrote: >>> Error 121 (EREMOTEIO) was returned from blkdev_issue_zeroout(). >>> That came from sd driver because WRITE SAME was sent to the device >>> which didn't support it. >>> >>> The problem

[PATCH v2] dm: don't allow ioctls to targets that don't map to whole devices

.. at least for unprivileged users. Before we called into the SCSI ioctl code to allow excemptions for a few SCSI passthrough ioctls, but this is pretty unsafe and except for this call dm knows nothing about SCSI ioctls. As the SCSI ioctl code is now optional, we really don't want to drag it in

Re: [PATCH v2] dm: don't allow ioctls to targets that don't map to whole devices

On Fri, Feb 03 2017 at 11:22am -0500, Christoph Hellwig wrote: > .. at least for unprivileged users. Before we called into the SCSI > ioctl code to allow excemptions for a few SCSI passthrough ioctls, > but this is pretty unsafe and except for this call dm knows nothing > about

[PATCH v3] dm: don't allow ioctls to targets that don't map to whole devices

.. at least for unprivileged users. Before we called into the SCSI ioctl code to allow excemptions for a few SCSI passthrough ioctls, but this is pretty unsafe and except for this call dm knows nothing about SCSI ioctls. As the SCSI ioctl code is now optional, we really don't want to drag it in

Re: [PATCH 3/6] genirq/affinity: update CPU affinity for CPU hotplug events

Hi Christoph, [auto build test ERROR on block/for-next] [also build test ERROR on v4.10-rc6] [cannot apply to next-20170203] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Christoph-Hellwig

Re: [PATCH v3] dm: don't allow ioctls to targets that don't map to whole devices

On Fri, Feb 03 2017 at 11:37am -0500, Christoph Hellwig wrote: > .. at least for unprivileged users. Before we called into the SCSI > ioctl code to allow excemptions for a few SCSI passthrough ioctls, > but this is pretty unsafe and except for this call dm knows nothing > about

Re: [PATCH v3] dm: don't allow ioctls to targets that don't map to whole devices

On Fri, Feb 03, 2017 at 11:39:22AM -0500, Mike Snitzer wrote: > I assume you meant for v3 to remove the newline? ;) I did. And I swear I did edit the file, but I guess the ammend didn't work. I guess it's time for the weekend.. I'll resend after I got some rest.

Re: [PATCH 1/2] blk-merge: return the merged request

On Thu, Feb 02, 2017 at 09:06:12AM -0700, Jens Axboe wrote: > When we attempt to merge request-to-request, we return a 0/1 if we > ended up merging or not. Change that to return the pointer to the > request that we freed. We will use this to move the freeing of > that request out of the merge

Re: [PATCH 2/2] block: free merged request in the caller

On Thu, Feb 02, 2017 at 09:06:13AM -0700, Jens Axboe wrote: > If we end up doing a request-to-request merge when we have completed > a bio-to-request merge, we free the request from deep down in that > path. For blk-mq-sched, the merge path has to hold the appropriate > lock, but we don't need it

Re: [PATCH v3] dm: don't allow ioctls to targets that don't map to whole devices

On 03/02/2017 08:37, Christoph Hellwig wrote: > .. at least for unprivileged users. Before we called into the SCSI > ioctl code to allow excemptions for a few SCSI passthrough ioctls, > but this is pretty unsafe and except for this call dm knows nothing > about SCSI ioctls. > > As the SCSI