* [PATCH] x86/paravirt: Guard against invalid cpu # in pv_vcpu_is_preempted()
From: Waiman Long @ 2019-03-25 15:57 UTC (permalink / raw)
To: Juergen Gross, Alok Kataria, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H. Peter Anvin, Peter Zijlstra, Will Deacon
Cc: Waiman Long, Paolo Bonzini, x86, linux-kernel, virtualization
It was found that passing an invalid cpu number to pv_vcpu_is_preempted()
might panic the kernel in a VM guest. For example,
[ 2.531077] Oops: 0000 [#1] SMP PTI
:
[ 2.532545] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
[ 2.533321] RIP: 0010:__raw_callee_save___kvm_vcpu_is_preempted+0x0/0x20
To guard against this kind of kernel panic, check is added to
pv_vcpu_is_preempted() to make sure that no invalid cpu number will
be used.
Signed-off-by: Waiman Long <longman@redhat.com>
---
arch/x86/include/asm/paravirt.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index c25c38a05c1c..4cfb465dcde4 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -671,6 +671,12 @@ static __always_inline void pv_kick(int cpu)
static __always_inline bool pv_vcpu_is_preempted(long cpu)
{
+ /*
+ * Guard against invalid cpu number or the kernel might panic.
+ */
+ if (WARN_ON_ONCE((unsigned long)cpu >= nr_cpu_ids))
+ return false;
+
return PVOP_CALLEE1(bool, lock.vcpu_is_preempted, cpu);
}
--
2.18.1
^ permalink raw reply related
* Re: [PATCH] x86/paravirt: Guard against invalid cpu # in pv_vcpu_is_preempted()
From: Juergen Gross @ 2019-03-25 16:40 UTC (permalink / raw)
To: Waiman Long, Alok Kataria, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H. Peter Anvin, Peter Zijlstra, Will Deacon
Cc: Paolo Bonzini, x86, linux-kernel, virtualization
In-Reply-To: <20190325155706.26987-1-longman@redhat.com>
On 25/03/2019 16:57, Waiman Long wrote:
> It was found that passing an invalid cpu number to pv_vcpu_is_preempted()
> might panic the kernel in a VM guest. For example,
>
> [ 2.531077] Oops: 0000 [#1] SMP PTI
> :
> [ 2.532545] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
> [ 2.533321] RIP: 0010:__raw_callee_save___kvm_vcpu_is_preempted+0x0/0x20
>
> To guard against this kind of kernel panic, check is added to
> pv_vcpu_is_preempted() to make sure that no invalid cpu number will
> be used.
>
> Signed-off-by: Waiman Long <longman@redhat.com>
> ---
> arch/x86/include/asm/paravirt.h | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
> index c25c38a05c1c..4cfb465dcde4 100644
> --- a/arch/x86/include/asm/paravirt.h
> +++ b/arch/x86/include/asm/paravirt.h
> @@ -671,6 +671,12 @@ static __always_inline void pv_kick(int cpu)
>
> static __always_inline bool pv_vcpu_is_preempted(long cpu)
> {
> + /*
> + * Guard against invalid cpu number or the kernel might panic.
> + */
> + if (WARN_ON_ONCE((unsigned long)cpu >= nr_cpu_ids))
> + return false;
> +
> return PVOP_CALLEE1(bool, lock.vcpu_is_preempted, cpu);
> }
Can this really happen without being a programming error?
Basically you'd need to guard all percpu area accesses to foreign cpus
this way. Why is this one special?
Juergen
^ permalink raw reply
* Re: [PATCH] x86/paravirt: Guard against invalid cpu # in pv_vcpu_is_preempted()
From: Waiman Long @ 2019-03-25 18:03 UTC (permalink / raw)
To: Juergen Gross, Alok Kataria, Thomas Gleixner, Ingo Molnar,
Borislav Petkov, H. Peter Anvin, Peter Zijlstra, Will Deacon
Cc: Paolo Bonzini, x86, linux-kernel, virtualization
In-Reply-To: <e01da674-cbf0-22f1-7aba-6041f892b689@suse.com>
On 03/25/2019 12:40 PM, Juergen Gross wrote:
> On 25/03/2019 16:57, Waiman Long wrote:
>> It was found that passing an invalid cpu number to pv_vcpu_is_preempted()
>> might panic the kernel in a VM guest. For example,
>>
>> [ 2.531077] Oops: 0000 [#1] SMP PTI
>> :
>> [ 2.532545] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
>> [ 2.533321] RIP: 0010:__raw_callee_save___kvm_vcpu_is_preempted+0x0/0x20
>>
>> To guard against this kind of kernel panic, check is added to
>> pv_vcpu_is_preempted() to make sure that no invalid cpu number will
>> be used.
>>
>> Signed-off-by: Waiman Long <longman@redhat.com>
>> ---
>> arch/x86/include/asm/paravirt.h | 6 ++++++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
>> index c25c38a05c1c..4cfb465dcde4 100644
>> --- a/arch/x86/include/asm/paravirt.h
>> +++ b/arch/x86/include/asm/paravirt.h
>> @@ -671,6 +671,12 @@ static __always_inline void pv_kick(int cpu)
>>
>> static __always_inline bool pv_vcpu_is_preempted(long cpu)
>> {
>> + /*
>> + * Guard against invalid cpu number or the kernel might panic.
>> + */
>> + if (WARN_ON_ONCE((unsigned long)cpu >= nr_cpu_ids))
>> + return false;
>> +
>> return PVOP_CALLEE1(bool, lock.vcpu_is_preempted, cpu);
>> }
> Can this really happen without being a programming error?
This shouldn't happen without a programming error, I think. In my case,
it was caused by a race condition leading to use-after-free of the cpu
number. However, my point is that error like that shouldn't cause the
kernel to panic.
> Basically you'd need to guard all percpu area accesses to foreign cpus
> this way. Why is this one special?
It depends. If out-of-bound access can only happen with obvious
programming error, I don't think we need to guard against them. In this
case, I am not totally sure if the race condition that I found may
happen with existing code or not. To be prudent, I decide to send this
patch out.
The race condition that I am looking at is as follows:
CPU 0 CPU 1
----- -----
up_write:
owner = NULL;
<release-barrier>
count = 0;
<rcu-free task structure>
rwsem_can_spin_on_owner:
rcu_read_lock();
read owner;
:
vcpu_is_preempted(owner->cpu);
:
rcu_read_unlock()
When I tried to merge the owner into the count (clear the owner after
the barrier), I can reproduce the crash 100% when booting up the kernel
in a VM guest. However, I am not sure if the configuration above is safe
and is just very hard to reproduce.
Alternatively, I can also do the cpu check before calling
vcpu_is_preempted().
Cheers,
Longman
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: INFO: task hung in vhost_net_stop_vq
From: Jason Wang @ 2019-03-26 10:17 UTC (permalink / raw)
To: Michael S. Tsirkin, syzbot
Cc: weiyj.lk, kvm, netdev, syzkaller-bugs, linux-kernel,
virtualization
In-Reply-To: <20190325100223-mutt-send-email-mst@kernel.org>
On 2019/3/25 下午10:02, Michael S. Tsirkin wrote:
> Looks like more iotlb locking mess?
Looking at the calltrace:
[ 221.743675] =============================================
[ 221.744297] [ INFO: possible recursive locking detected ]
[ 221.744944] 4.7.0+ #1 Not tainted
[ 221.745326] ---------------------------------------------
[ 221.746128] syz-executor1/6823 is trying to acquire lock:
[ 221.746737] (&vq->mutex){+.+...}, at: [<ffffffff84484b70>] vhost_process_iotlb_msg+0xe0/0x9e0
[ 221.747789]
[ 221.747789] but task is already holding lock:
[ 221.748470] (&vq->mutex){+.+...}, at: [<ffffffff84484b70>] vhost_process_iotlb_msg+0xe0/0x9e0
[ 221.749535]
[ 221.749535] other info that might help us debug this:
[ 221.750280] Possible unsafe locking scenario:
[ 221.750280]
[ 221.750946] CPU0
[ 221.751232] ----
[ 221.751523] lock(&vq->mutex);
[ 221.751922] lock(&vq->mutex);
[ 221.752339]
[ 221.752339] *** DEADLOCK ***
[ 221.752339]
I could not think of a path that can hit this. And I could not reproduce with the reproducer in the link in net-next.
Thanks
>
> On Tue, Mar 19, 2019 at 10:21:00PM -0700, syzbot wrote:
>> syzbot has bisected this bug to:
>>
>> commit 6b1e6cc7855b09a0a9bfa1d9f30172ba366f161c
>> Author: Jason Wang <jasowang@redhat.com>
>> Date: Thu Jun 23 06:04:32 2016 +0000
>>
>> vhost: new device IOTLB API
>>
>> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1486ad27200000
>> start commit: 6b1e6cc7 vhost: new device IOTLB API
>> git tree: upstream
>> final crash: https://syzkaller.appspot.com/x/report.txt?x=1686ad27200000
>> console output: https://syzkaller.appspot.com/x/log.txt?x=1286ad27200000
>> kernel config: https://syzkaller.appspot.com/x/.config?x=c94f9f0c0363db4b
>> dashboard link: https://syzkaller.appspot.com/bug?extid=d21e6e297322a900c128
>> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=141db34d400000
>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=108ef293400000
>>
>> Reported-by: syzbot+d21e6e297322a900c128@syzkaller.appspotmail.com
>> Fixes: 6b1e6cc7 ("vhost: new device IOTLB API")
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: INFO: task hung in vhost_net_stop_vq
From: Dmitry Vyukov via Virtualization @ 2019-03-26 10:28 UTC (permalink / raw)
To: Jason Wang
Cc: syzbot, weiyj.lk, KVM list, Michael S. Tsirkin, netdev,
syzkaller-bugs, LKML, virtualization
In-Reply-To: <df4f2cf6-8469-f894-8f45-7c48a6a1801f@redhat.com>
On Tue, Mar 26, 2019 at 11:17 AM Jason Wang <jasowang@redhat.com> wrote:
>
>
> On 2019/3/25 下午10:02, Michael S. Tsirkin wrote:
> > Looks like more iotlb locking mess?
>
>
> Looking at the calltrace:
>
> [ 221.743675] =============================================
> [ 221.744297] [ INFO: possible recursive locking detected ]
> [ 221.744944] 4.7.0+ #1 Not tainted
> [ 221.745326] ---------------------------------------------
> [ 221.746128] syz-executor1/6823 is trying to acquire lock:
> [ 221.746737] (&vq->mutex){+.+...}, at: [<ffffffff84484b70>] vhost_process_iotlb_msg+0xe0/0x9e0
> [ 221.747789]
> [ 221.747789] but task is already holding lock:
> [ 221.748470] (&vq->mutex){+.+...}, at: [<ffffffff84484b70>] vhost_process_iotlb_msg+0xe0/0x9e0
> [ 221.749535]
> [ 221.749535] other info that might help us debug this:
> [ 221.750280] Possible unsafe locking scenario:
> [ 221.750280]
> [ 221.750946] CPU0
> [ 221.751232] ----
> [ 221.751523] lock(&vq->mutex);
> [ 221.751922] lock(&vq->mutex);
> [ 221.752339]
> [ 221.752339] *** DEADLOCK ***
> [ 221.752339]
>
> I could not think of a path that can hit this. And I could not reproduce with the reproducer in the link in net-next.
Looking at the bisection log, syzbot is able to reproduce this
super-reliably on multiple kernel revisions. Are you sure you are
using the right config/revision? What else can be in play? syzbot uses
VMs. The image is available.
> Thanks
>
>
> >
> > On Tue, Mar 19, 2019 at 10:21:00PM -0700, syzbot wrote:
> >> syzbot has bisected this bug to:
> >>
> >> commit 6b1e6cc7855b09a0a9bfa1d9f30172ba366f161c
> >> Author: Jason Wang <jasowang@redhat.com>
> >> Date: Thu Jun 23 06:04:32 2016 +0000
> >>
> >> vhost: new device IOTLB API
> >>
> >> bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=1486ad27200000
> >> start commit: 6b1e6cc7 vhost: new device IOTLB API
> >> git tree: upstream
> >> final crash: https://syzkaller.appspot.com/x/report.txt?x=1686ad27200000
> >> console output: https://syzkaller.appspot.com/x/log.txt?x=1286ad27200000
> >> kernel config: https://syzkaller.appspot.com/x/.config?x=c94f9f0c0363db4b
> >> dashboard link: https://syzkaller.appspot.com/bug?extid=d21e6e297322a900c128
> >> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=141db34d400000
> >> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=108ef293400000
> >>
> >> Reported-by: syzbot+d21e6e297322a900c128@syzkaller.appspotmail.com
> >> Fixes: 6b1e6cc7 ("vhost: new device IOTLB API")
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller-bugs" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller-bugs+unsubscribe@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/syzkaller-bugs/df4f2cf6-8469-f894-8f45-7c48a6a1801f%40redhat.com.
> For more options, visit https://groups.google.com/d/optout.
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [RFC PATCH] virtio_ring: Use DMA API if guest memory is encrypted
From: Michael S. Tsirkin @ 2019-03-26 16:53 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Lorenzo.Pieralisi, tnowicki, Jean-Philippe Brucker,
Benjamin Herrenschmidt, Alexey Kardashevskiy, Ram Pai,
linux-kernel, Will.Deacon, virtualization, Paul Mackerras,
eric.auger, iommu, Marc.Zyngier, Robin.Murphy, linuxppc-dev, joro,
David Gibson
In-Reply-To: <20190130074427.GA29516@lst.de>
On Wed, Jan 30, 2019 at 08:44:27AM +0100, Christoph Hellwig wrote:
> On Tue, Jan 29, 2019 at 09:36:08PM -0500, Michael S. Tsirkin wrote:
> > This has been discussed ad nauseum. virtio is all about compatibility.
> > Losing a couple of lines of code isn't worth breaking working setups.
> > People that want "just use DMA API no tricks" now have the option.
> > Setting a flag in a feature bit map is literally a single line
> > of code in the hypervisor. So stop pushing for breaking working
> > legacy setups and just fix it in the right place.
>
> I agree with the legacy aspect. What I am missing is an extremely
> strong wording that says you SHOULD always set this flag for new
> hosts, including an explanation why.
So as far as power is concerned, IIUC the issue they are struggling with is
that some platforms do not support pass-through mode in the emulated IOMMU.
Disabling PLATFORM_ACCESS is so far a way around that, unfortunately just for
virtio devices. I would like virtio-iommu to be able to address that need as
well.
--
MST
^ permalink raw reply
* Re: [PATCH net v3] failover: allow name change on IFF_UP slave interfaces
From: Stephen Hemminger @ 2019-03-27 2:13 UTC (permalink / raw)
To: Si-Wei Liu
Cc: jiri, mst, kubakici, sridhar.samudrala, alexander.duyck,
virtualization, liran.alon, netdev, boris.ostrovsky, davem
In-Reply-To: <1553644093-10917-1-git-send-email-si-wei.liu@oracle.com>
On Tue, 26 Mar 2019 19:48:13 -0400
Si-Wei Liu <si-wei.liu@oracle.com> wrote:
> When a netdev appears through hot plug then gets enslaved by a failover
> master that is already up and running, the slave will be opened
> right away after getting enslaved. Today there's a race that userspace
> (udev) may fail to rename the slave if the kernel (net_failover)
> opens the slave earlier than when the userspace rename happens.
> Unlike bond or team, the primary slave of failover can't be renamed by
> userspace ahead of time, since the kernel initiated auto-enslavement is
> unable to, or rather, is never meant to be synchronized with the rename
> request from userspace.
>
> As the failover slave interfaces are not designed to be operated
> directly by userspace apps: IP configuration, filter rules with
> regard to network traffic passing and etc., should all be done on master
> interface. In general, userspace apps only care about the
> name of master interface, while slave names are less important as long
> as admin users can see reliable names that may carry
> other information describing the netdev. For e.g., they can infer that
> "ens3nsby" is a standby slave of "ens3", while for a
> name like "eth0" they can't tell which master it belongs to.
>
> Historically the name of IFF_UP interface can't be changed because
> there might be admin script or management software that is already
> relying on such behavior and assumes that the slave name can't be
> changed once UP. But failover is special: with the in-kernel
> auto-enslavement mechanism, the userspace expectation for device
> enumeration and bring-up order is already broken. Previously initramfs
> and various userspace config tools were modified to bypass failover
> slaves because of auto-enslavement and duplicate MAC address. Similarly,
> in case that users care about seeing reliable slave name, the new type
> of failover slaves needs to be taken care of specifically in userspace
> anyway.
>
> It's less risky to lift up the rename restriction on failover slave
> which is already UP. Although it's possible this change may potentially
> break userspace component (most likely configuration scripts or
> management software) that assumes slave name can't be changed while
> UP, it's relatively a limited and controllable set among all userspace
> components, which can be fixed specifically to listen for the rename
> and/or link down/up events on failover slaves. Userspace component
> interacting with slaves is expected to be changed to operate on failover
> master interface instead, as the failover slave is dynamic in nature
> which may come and go at any point. The goal is to make the role of
> failover slaves less relevant, and userspace components should only
> deal with failover master in the long run.
>
> Fixes: 30c8bd5aa8b2 ("net: Introduce generic failover module")
> Signed-off-by: Si-Wei Liu <si-wei.liu@oracle.com>
> Reviewed-by: Liran Alon <liran.alon@oracle.com>
Why do you need to do dev_close/dev_open which will bounce
the link?
^ permalink raw reply
* [PATCH 0/2] Limit number of hw queues by nr_cpu_ids for virtio-blk and virtio-scsi
From: Dongli Zhang @ 2019-03-27 10:36 UTC (permalink / raw)
To: linux-scsi, virtualization, linux-block
Cc: axboe, martin.petersen, mst, cohuck, linux-kernel, jejb
When tag_set->nr_maps is 1, the block layer limits the number of hw queues
by nr_cpu_ids. No matter how many hw queues are use by
virtio-blk/virtio-scsi, as they both have (tag_set->nr_maps == 1), they
can use at most nr_cpu_ids hw queues.
In addition, specifically for pci scenario, when the 'num-queues' specified
by qemu is more than maxcpus, virtio-blk/virtio-scsi would not be able to
allocate more than maxcpus vectors in order to have a vector for each
queue. As a result, they fall back into MSI-X with one vector for config
and one shared for queues.
Considering above reasons, this patch set limits the number of hw queues
used by nr_cpu_ids for both virtio-blk and virtio-scsi.
-------------------------------------------------------------
Here is test result of virtio-scsi:
qemu cmdline:
-smp 2,maxcpus=4, \
-device virtio-scsi-pci,id=scsi0,num_queues=8, \
-device scsi-hd,drive=drive0,bus=scsi0.0,channel=0,scsi-id=0,lun=0, \
-drive file=test.img,if=none,id=drive0
Although maxcpus=4 and num_queues=8, 4 queues are used while 2 interrupts
are allocated.
# cat /proc/interrupts
... ...
24: 0 0 PCI-MSI 65536-edge virtio0-config
25: 0 369 PCI-MSI 65537-edge virtio0-virtqueues
... ...
# /sys/block/sda/mq/
0 1 2 3 ------> 4 queues although qemu sets num_queues=8
With the patch set, there is per-queue interrupt.
# cat /proc/interrupts
24: 0 0 PCI-MSI 65536-edge virtio0-config
25: 0 0 PCI-MSI 65537-edge virtio0-control
26: 0 0 PCI-MSI 65538-edge virtio0-event
27: 296 0 PCI-MSI 65539-edge virtio0-request
28: 0 139 PCI-MSI 65540-edge virtio0-request
29: 0 0 PCI-MSI 65541-edge virtio0-request
30: 0 0 PCI-MSI 65542-edge virtio0-request
# ls /sys/block/sda/mq
0 1 2 3
-------------------------------------------------------------
Here is test result of virtio-blk:
qemu cmdline:
-smp 2,maxcpus=4,
-device virtio-blk-pci,drive=drive-virtio-disk0,id=virtio-disk0,num-queues=8
-drive test.img,format=raw,if=none,id=drive-virtio-disk0
Although maxcpus=4 and num-queues=8, 4 queues are used while 2 interrupts
are allocated.
# cat /proc/interrupts
... ...
24: 0 0 PCI-MSI 65536-edge virtio0-config
25: 0 65 PCI-MSI 65537-edge virtio0-virtqueues
... ...
# ls /sys/block/vda/mq
0 1 2 3 -------> 4 queues although qemu sets num_queues=8
With the patch set, there is per-queue interrupt.
# cat /proc/interrupts
24: 0 0 PCI-MSI 65536-edge virtio0-config
25: 64 0 PCI-MSI 65537-edge virtio0-req.0
26: 0 10290 PCI-MSI 65538-edge virtio0-req.1
27: 0 0 PCI-MSI 65539-edge virtio0-req.2
28: 0 0 PCI-MSI 65540-edge virtio0-req.3
# ls /sys/block/vda/mq/
0 1 2 3
Reference: https://lore.kernel.org/lkml/e4afe4c5-0262-4500-aeec-60f30734b4fc@default/
Thank you very much!
Dongli Zhang
^ permalink raw reply
* [PATCH 1/2] virtio-blk: limit number of hw queues by nr_cpu_ids
From: Dongli Zhang @ 2019-03-27 10:36 UTC (permalink / raw)
To: linux-scsi, virtualization, linux-block
Cc: axboe, martin.petersen, mst, cohuck, linux-kernel, jejb
In-Reply-To: <1553682995-5682-1-git-send-email-dongli.zhang@oracle.com>
When tag_set->nr_maps is 1, the block layer limits the number of hw queues
by nr_cpu_ids. No matter how many hw queues are used by virtio-blk, as it
has (tag_set->nr_maps == 1), it can use at most nr_cpu_ids hw queues.
In addition, specifically for pci scenario, when the 'num-queues' specified
by qemu is more than maxcpus, virtio-blk would not be able to allocate more
than maxcpus vectors in order to have a vector for each queue. As a result,
it falls back into MSI-X with one vector for config and one shared for
queues.
Considering above reasons, this patch limits the number of hw queues used
by virtio-blk by nr_cpu_ids.
Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
---
drivers/block/virtio_blk.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 4bc083b..b83cb45 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -513,6 +513,8 @@ static int init_vq(struct virtio_blk *vblk)
if (err)
num_vqs = 1;
+ num_vqs = min_t(unsigned int, nr_cpu_ids, num_vqs);
+
vblk->vqs = kmalloc_array(num_vqs, sizeof(*vblk->vqs), GFP_KERNEL);
if (!vblk->vqs)
return -ENOMEM;
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] scsi: virtio_scsi: limit number of hw queues by nr_cpu_ids
From: Dongli Zhang @ 2019-03-27 10:36 UTC (permalink / raw)
To: linux-scsi, virtualization, linux-block
Cc: axboe, martin.petersen, mst, cohuck, linux-kernel, jejb
In-Reply-To: <1553682995-5682-1-git-send-email-dongli.zhang@oracle.com>
When tag_set->nr_maps is 1, the block layer limits the number of hw queues
by nr_cpu_ids. No matter how many hw queues are used by virtio-scsi, as it
has (tag_set->nr_maps == 1), it can use at most nr_cpu_ids hw queues.
In addition, specifically for pci scenario, when the 'num_queues' specified
by qemu is more than maxcpus, virtio-scsi would not be able to allocate
more than maxcpus vectors in order to have a vector for each queue. As a
result, it falls back into MSI-X with one vector for config and one shared
for queues.
Considering above reasons, this patch limits the number of hw queues used
by virtio-scsi by nr_cpu_ids.
Signed-off-by: Dongli Zhang <dongli.zhang@oracle.com>
---
drivers/scsi/virtio_scsi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/scsi/virtio_scsi.c b/drivers/scsi/virtio_scsi.c
index 8af0177..9c4a3e1 100644
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@ -793,6 +793,7 @@ static int virtscsi_probe(struct virtio_device *vdev)
/* We need to know how many queues before we allocate. */
num_queues = virtscsi_config_get(vdev, num_queues) ? : 1;
+ num_queues = min_t(unsigned int, nr_cpu_ids, num_queues);
num_targets = virtscsi_config_get(vdev, max_target) + 1;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH net v3] failover: allow name change on IFF_UP slave interfaces
From: Jiri Pirko @ 2019-03-27 11:11 UTC (permalink / raw)
To: Si-Wei Liu
Cc: mst, kubakici, sridhar.samudrala, alexander.duyck, virtualization,
liran.alon, netdev, boris.ostrovsky, davem
In-Reply-To: <1553644093-10917-1-git-send-email-si-wei.liu@oracle.com>
Wed, Mar 27, 2019 at 12:48:13AM CET, si-wei.liu@oracle.com wrote:
>When a netdev appears through hot plug then gets enslaved by a failover
>master that is already up and running, the slave will be opened
>right away after getting enslaved. Today there's a race that userspace
>(udev) may fail to rename the slave if the kernel (net_failover)
>opens the slave earlier than when the userspace rename happens.
>Unlike bond or team, the primary slave of failover can't be renamed by
>userspace ahead of time, since the kernel initiated auto-enslavement is
>unable to, or rather, is never meant to be synchronized with the rename
>request from userspace.
>
>As the failover slave interfaces are not designed to be operated
>directly by userspace apps: IP configuration, filter rules with
>regard to network traffic passing and etc., should all be done on master
>interface. In general, userspace apps only care about the
>name of master interface, while slave names are less important as long
>as admin users can see reliable names that may carry
>other information describing the netdev. For e.g., they can infer that
>"ens3nsby" is a standby slave of "ens3", while for a
>name like "eth0" they can't tell which master it belongs to.
>
>Historically the name of IFF_UP interface can't be changed because
>there might be admin script or management software that is already
>relying on such behavior and assumes that the slave name can't be
>changed once UP. But failover is special: with the in-kernel
>auto-enslavement mechanism, the userspace expectation for device
>enumeration and bring-up order is already broken. Previously initramfs
>and various userspace config tools were modified to bypass failover
>slaves because of auto-enslavement and duplicate MAC address. Similarly,
>in case that users care about seeing reliable slave name, the new type
>of failover slaves needs to be taken care of specifically in userspace
>anyway.
>
>It's less risky to lift up the rename restriction on failover slave
>which is already UP. Although it's possible this change may potentially
>break userspace component (most likely configuration scripts or
>management software) that assumes slave name can't be changed while
>UP, it's relatively a limited and controllable set among all userspace
>components, which can be fixed specifically to listen for the rename
>and/or link down/up events on failover slaves. Userspace component
>interacting with slaves is expected to be changed to operate on failover
>master interface instead, as the failover slave is dynamic in nature
>which may come and go at any point. The goal is to make the role of
>failover slaves less relevant, and userspace components should only
>deal with failover master in the long run.
>
>Fixes: 30c8bd5aa8b2 ("net: Introduce generic failover module")
>Signed-off-by: Si-Wei Liu <si-wei.liu@oracle.com>
>Reviewed-by: Liran Alon <liran.alon@oracle.com>
>
>--
>v1 -> v2:
>- Drop configurable module parameter (Sridhar)
>
>v2 -> v3:
>- Drop additional IFF_SLAVE_RENAME_OK flag (Sridhar)
>- Send down and up events around rename (Michael S. Tsirkin)
>---
> net/core/dev.c | 37 ++++++++++++++++++++++++++++++++++---
> 1 file changed, 34 insertions(+), 3 deletions(-)
>
>diff --git a/net/core/dev.c b/net/core/dev.c
>index 722d50d..3e0cd80 100644
>--- a/net/core/dev.c
>+++ b/net/core/dev.c
>@@ -1171,6 +1171,7 @@ int dev_get_valid_name(struct net *net, struct net_device *dev,
> int dev_change_name(struct net_device *dev, const char *newname)
> {
> unsigned char old_assign_type;
>+ bool reopen_needed = false;
> char oldname[IFNAMSIZ];
> int err = 0;
> int ret;
>@@ -1180,8 +1181,24 @@ int dev_change_name(struct net_device *dev, const char *newname)
> BUG_ON(!dev_net(dev));
>
> net = dev_net(dev);
>- if (dev->flags & IFF_UP)
>- return -EBUSY;
>+
>+ /* Allow failover slave to rename even when
>+ * it is up and running.
>+ *
>+ * Failover slaves are special, since userspace
>+ * might rename the slave after the interface
>+ * has been brought up and running due to
>+ * auto-enslavement.
>+ *
>+ * Failover users don't actually care about slave
>+ * name change, as they are only expected to operate
>+ * on master interface directly.
>+ */
>+ if (dev->flags & IFF_UP) {
>+ if (likely(!(dev->priv_flags & IFF_FAILOVER_SLAVE)))
>+ return -EBUSY;
>+ reopen_needed = true;
>+ }
>
> write_seqcount_begin(&devnet_rename_seq);
>
>@@ -1198,6 +1215,9 @@ int dev_change_name(struct net_device *dev, const char *newname)
> return err;
> }
>
>+ if (reopen_needed)
>+ dev_close(dev);
Ugh. Don't dev_close/dev_open on name change.
>+
> if (oldname[0] && !strchr(oldname, '%'))
> netdev_info(dev, "renamed from %s\n", oldname);
>
>@@ -1210,7 +1230,9 @@ int dev_change_name(struct net_device *dev, const char *newname)
> memcpy(dev->name, oldname, IFNAMSIZ);
> dev->name_assign_type = old_assign_type;
> write_seqcount_end(&devnet_rename_seq);
>- return ret;
>+ if (err >= 0)
>+ err = ret;
>+ goto reopen;
> }
>
> write_seqcount_end(&devnet_rename_seq);
>@@ -1246,6 +1268,15 @@ int dev_change_name(struct net_device *dev, const char *newname)
> }
> }
>
>+reopen:
>+ if (reopen_needed) {
>+ ret = dev_open(dev);
>+ if (ret) {
>+ pr_err("%s: reopen device failed: %d\n",
>+ dev->name, ret);
>+ }
>+ }
>+
> return err;
> }
>
>--
>1.8.3.1
>
^ permalink raw reply
* Re: [PATCH net v3] failover: allow name change on IFF_UP slave interfaces
From: Michael S. Tsirkin @ 2019-03-27 13:25 UTC (permalink / raw)
To: Stephen Hemminger
Cc: jiri, kubakici, sridhar.samudrala, alexander.duyck,
virtualization, liran.alon, netdev, Si-Wei Liu, boris.ostrovsky,
davem
In-Reply-To: <20190326191342.11f0cb55@shemminger-XPS-13-9360>
On Tue, Mar 26, 2019 at 07:13:42PM -0700, Stephen Hemminger wrote:
> On Tue, 26 Mar 2019 19:48:13 -0400
> Si-Wei Liu <si-wei.liu@oracle.com> wrote:
>
> > When a netdev appears through hot plug then gets enslaved by a failover
> > master that is already up and running, the slave will be opened
> > right away after getting enslaved. Today there's a race that userspace
> > (udev) may fail to rename the slave if the kernel (net_failover)
> > opens the slave earlier than when the userspace rename happens.
> > Unlike bond or team, the primary slave of failover can't be renamed by
> > userspace ahead of time, since the kernel initiated auto-enslavement is
> > unable to, or rather, is never meant to be synchronized with the rename
> > request from userspace.
> >
> > As the failover slave interfaces are not designed to be operated
> > directly by userspace apps: IP configuration, filter rules with
> > regard to network traffic passing and etc., should all be done on master
> > interface. In general, userspace apps only care about the
> > name of master interface, while slave names are less important as long
> > as admin users can see reliable names that may carry
> > other information describing the netdev. For e.g., they can infer that
> > "ens3nsby" is a standby slave of "ens3", while for a
> > name like "eth0" they can't tell which master it belongs to.
> >
> > Historically the name of IFF_UP interface can't be changed because
> > there might be admin script or management software that is already
> > relying on such behavior and assumes that the slave name can't be
> > changed once UP. But failover is special: with the in-kernel
> > auto-enslavement mechanism, the userspace expectation for device
> > enumeration and bring-up order is already broken. Previously initramfs
> > and various userspace config tools were modified to bypass failover
> > slaves because of auto-enslavement and duplicate MAC address. Similarly,
> > in case that users care about seeing reliable slave name, the new type
> > of failover slaves needs to be taken care of specifically in userspace
> > anyway.
> >
> > It's less risky to lift up the rename restriction on failover slave
> > which is already UP. Although it's possible this change may potentially
> > break userspace component (most likely configuration scripts or
> > management software) that assumes slave name can't be changed while
> > UP, it's relatively a limited and controllable set among all userspace
> > components, which can be fixed specifically to listen for the rename
> > and/or link down/up events on failover slaves. Userspace component
> > interacting with slaves is expected to be changed to operate on failover
> > master interface instead, as the failover slave is dynamic in nature
> > which may come and go at any point. The goal is to make the role of
> > failover slaves less relevant, and userspace components should only
> > deal with failover master in the long run.
> >
> > Fixes: 30c8bd5aa8b2 ("net: Introduce generic failover module")
> > Signed-off-by: Si-Wei Liu <si-wei.liu@oracle.com>
> > Reviewed-by: Liran Alon <liran.alon@oracle.com>
>
>
> Why do you need to do dev_close/dev_open which will bounce
> the link?
What we need is notify userspace that link went up/down.
close/open will do that but just sending notifications
would do that as well without playing with link states.
--
MST
^ permalink raw reply
* Re: [PATCH] drm/virtio: add virtio-gpu-features debugfs file.
From: Noralf Trønnes @ 2019-03-27 13:49 UTC (permalink / raw)
To: Gerd Hoffmann, dri-devel
Cc: David Airlie, open list, open list:VIRTIO GPU DRIVER
In-Reply-To: <20190320083612.32067-1-kraxel@redhat.com>
Den 20.03.2019 09.36, skrev Gerd Hoffmann:
> This file prints which features the virtio-gpu device has.
>
> Also add "virtio-gpu-" prefix to the existing fence file,
> to make clear this is a driver-specific debugfs file.
>
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
Acked-by: Noralf Trønnes <noralf@tronnes.org>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* [PATCH] MAiNTAINERS: add Paolo, Stefan for virtio blk/scsi
From: Michael S. Tsirkin @ 2019-03-27 14:33 UTC (permalink / raw)
To: pbonzini, stefanha, virtualization
Jason doesn't really have the time to review blk/scsi
patches. Paolo and Setfan agreed to help out.
Thanks guys!
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
diff --git a/MAINTAINERS b/MAINTAINERS
index 95a5ebecd04f..8326d19c1681 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -16247,7 +16247,7 @@ F: drivers/char/virtio_console.c
F: include/linux/virtio_console.h
F: include/uapi/linux/virtio_console.h
-VIRTIO CORE, NET AND BLOCK DRIVERS
+VIRTIO CORE AND NET DRIVERS
M: "Michael S. Tsirkin" <mst@redhat.com>
M: Jason Wang <jasowang@redhat.com>
L: virtualization@lists.linux-foundation.org
@@ -16262,6 +16262,18 @@ F: include/uapi/linux/virtio_*.h
F: drivers/crypto/virtio/
F: mm/balloon_compaction.c
+VIRTIO BLOCK AND SCSI DRIVERS
+M: "Michael S. Tsirkin" <mst@redhat.com>
+M: Paolo Bonzini <pbonzini@redhat.com>
+M: Stefan Hajnoczi <stefanha@redhat.com>
+L: virtualization@lists.linux-foundation.org
+S: Maintained
+F: drivers/block/virtio_blk.c
+F: drivers/scsi/virtio_scsi.c
+F: include/uapi/linux/virtio_blk.h
+F: include/uapi/linux/virtio_scsi.h
+F: drivers/vhost/scsi.c
+
VIRTIO CRYPTO DRIVER
M: Gonglei <arei.gonglei@huawei.com>
L: virtualization@lists.linux-foundation.org
^ permalink raw reply related
* Re: [PATCH v3 2/5] drm/virtio: use struct to pass params to virtio_gpu_object_create()
From: Noralf Trønnes @ 2019-03-27 14:35 UTC (permalink / raw)
To: Gerd Hoffmann, dri-devel
Cc: David Airlie, open list:VIRTIO GPU DRIVER, open list,
Daniel Vetter, Gurchetan Singh
In-Reply-To: <20190318113332.10900-3-kraxel@redhat.com>
Den 18.03.2019 12.33, skrev Gerd Hoffmann:
> Create virtio_gpu_object_params, use that to pass object parameters to
> virtio_gpu_object_create. This is just the first step, followup patches
> will add more parameters to the struct. The plan is to use the struct
> for all object parameters.
>
> Drop unused "kernel" parameter for virtio_gpu_alloc_object(), it is
> unused and always false.
>
> Also drop "pinned" parameter. virtio-gpu doesn't shuffle around
> objects, so effecively they all are pinned anyway. Hardcode
> TTM_PL_FLAG_NO_EVICT so ttm knows. Doesn't change much for the moment
> as virtio-gpu supports TTM_PL_FLAG_TT only so there is no opportunity to
> move around objects. That'll probably change in the future though.
>
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
Acked-by: Noralf Trønnes <noralf@tronnes.org>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH v3 5/5] drm/virtio: rework resource creation workflow.
From: Noralf Trønnes @ 2019-03-27 14:41 UTC (permalink / raw)
To: Gerd Hoffmann, dri-devel
Cc: David Airlie, open list:VIRTIO GPU DRIVER, open list,
Daniel Vetter, Gurchetan Singh
In-Reply-To: <20190318113332.10900-6-kraxel@redhat.com>
Den 18.03.2019 12.33, skrev Gerd Hoffmann:
> This patch moves the virtio_gpu_cmd_create_resource() call (which
> notifies the host about the new resource created) into the
> virtio_gpu_object_create() function. That way we can call
> virtio_gpu_cmd_create_resource() before ttm_bo_init(), so the host
> already knows about the object when ttm initializes the object and calls
> our driver callbacks.
>
> Specifically the object is already created when the
> virtio_gpu_ttm_tt_bind() callback invokes virtio_gpu_object_attach(),
> so the extra virtio_gpu_object_attach() calls done after
> virtio_gpu_object_create() are not needed any more.
>
> The fence support for the create ioctl becomes a bit more tricky though.
> The code moved into virtio_gpu_object_create() too. We first submit the
> (fenced) virtio_gpu_cmd_create_resource() command, then initialize the
> ttm object, and finally attach just created object to the fence for the
> command in case it didn't finish yet.
>
> Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
> ---
Acked-by: Noralf Trønnes <noralf@tronnes.org>
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH v2 -next] drm/virtio: remove set but not used variable 'vgdev'
From: Mukesh Ojha @ 2019-03-27 14:47 UTC (permalink / raw)
To: YueHaibing, David Airlie, Gerd Hoffmann, Daniel Vetter
Cc: kernel-janitors, linux-kernel, dri-devel, virtualization
In-Reply-To: <20190325092631.152060-1-yuehaibing@huawei.com>
On 3/25/2019 2:56 PM, YueHaibing wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/gpu/drm/virtio/virtgpu_ttm.c: In function 'virtio_gpu_init_mem_type':
> drivers/gpu/drm/virtio/virtgpu_ttm.c:117:28: warning:
> variable 'vgdev' set but not used [-Wunused-but-set-variable]
>
> drivers/gpu/drm/virtio/virtgpu_ttm.c: In function 'virtio_gpu_bo_swap_notify':
> drivers/gpu/drm/virtio/virtgpu_ttm.c:300:28: warning:
> variable 'vgdev' set but not used [-Wunused-but-set-variable]
>
> It is never used since introduction in dc5698e80cf7 ("Add virtio gpu driver.")
>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
-Mukesh
> ---
> v2: fix patch prefix
> ---
> drivers/gpu/drm/virtio/virtgpu_ttm.c | 6 ------
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/virtio/virtgpu_ttm.c b/drivers/gpu/drm/virtio/virtgpu_ttm.c
> index d6225ba20b30..eb007c2569d8 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_ttm.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_ttm.c
> @@ -114,10 +114,6 @@ static const struct ttm_mem_type_manager_func virtio_gpu_bo_manager_func = {
> static int virtio_gpu_init_mem_type(struct ttm_bo_device *bdev, uint32_t type,
> struct ttm_mem_type_manager *man)
> {
> - struct virtio_gpu_device *vgdev;
> -
> - vgdev = virtio_gpu_get_vgdev(bdev);
> -
> switch (type) {
> case TTM_PL_SYSTEM:
> /* System memory */
> @@ -297,10 +293,8 @@ static void virtio_gpu_bo_move_notify(struct ttm_buffer_object *tbo,
> static void virtio_gpu_bo_swap_notify(struct ttm_buffer_object *tbo)
> {
> struct virtio_gpu_object *bo;
> - struct virtio_gpu_device *vgdev;
>
> bo = container_of(tbo, struct virtio_gpu_object, tbo);
> - vgdev = (struct virtio_gpu_device *)bo->gem_base.dev->dev_private;
>
> if (bo->pages)
> virtio_gpu_object_free_sg_table(bo);
>
>
>
^ permalink raw reply
* Re: [PATCH] MAiNTAINERS: add Paolo, Stefan for virtio blk/scsi
From: Paolo Bonzini @ 2019-03-27 15:08 UTC (permalink / raw)
To: Michael S. Tsirkin, stefanha, virtualization
In-Reply-To: <20190327103254-mutt-send-email-mst@kernel.org>
On 27/03/19 15:33, Michael S. Tsirkin wrote:
> Jason doesn't really have the time to review blk/scsi
> patches. Paolo and Setfan agreed to help out.
>
> Thanks guys!
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>
> ---
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 95a5ebecd04f..8326d19c1681 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -16247,7 +16247,7 @@ F: drivers/char/virtio_console.c
> F: include/linux/virtio_console.h
> F: include/uapi/linux/virtio_console.h
>
> -VIRTIO CORE, NET AND BLOCK DRIVERS
> +VIRTIO CORE AND NET DRIVERS
> M: "Michael S. Tsirkin" <mst@redhat.com>
> M: Jason Wang <jasowang@redhat.com>
> L: virtualization@lists.linux-foundation.org
> @@ -16262,6 +16262,18 @@ F: include/uapi/linux/virtio_*.h
> F: drivers/crypto/virtio/
> F: mm/balloon_compaction.c
>
> +VIRTIO BLOCK AND SCSI DRIVERS
> +M: "Michael S. Tsirkin" <mst@redhat.com>
> +M: Paolo Bonzini <pbonzini@redhat.com>
> +M: Stefan Hajnoczi <stefanha@redhat.com>
Please make this R at least for me, so that it's clear that patches
still flow through your and Jason's tree. Not sure if you want to keep
Jason as M.
Paolo
> +L: virtualization@lists.linux-foundation.org
> +S: Maintained
> +F: drivers/block/virtio_blk.c
> +F: drivers/scsi/virtio_scsi.c
> +F: include/uapi/linux/virtio_blk.h
> +F: include/uapi/linux/virtio_scsi.h
> +F: drivers/vhost/scsi.c
> +
> VIRTIO CRYPTO DRIVER
> M: Gonglei <arei.gonglei@huawei.com>
> L: virtualization@lists.linux-foundation.org
>
^ permalink raw reply
* Re: [PATCH] MAiNTAINERS: add Paolo, Stefan for virtio blk/scsi
From: Michael S. Tsirkin @ 2019-03-27 15:36 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: stefanha, virtualization
In-Reply-To: <1a5d4b76-e11d-3a12-4971-64581bffe636@redhat.com>
On Wed, Mar 27, 2019 at 04:08:05PM +0100, Paolo Bonzini wrote:
> On 27/03/19 15:33, Michael S. Tsirkin wrote:
> > Jason doesn't really have the time to review blk/scsi
> > patches. Paolo and Setfan agreed to help out.
> >
> > Thanks guys!
> >
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> >
> > ---
> >
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 95a5ebecd04f..8326d19c1681 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -16247,7 +16247,7 @@ F: drivers/char/virtio_console.c
> > F: include/linux/virtio_console.h
> > F: include/uapi/linux/virtio_console.h
> >
> > -VIRTIO CORE, NET AND BLOCK DRIVERS
> > +VIRTIO CORE AND NET DRIVERS
> > M: "Michael S. Tsirkin" <mst@redhat.com>
> > M: Jason Wang <jasowang@redhat.com>
> > L: virtualization@lists.linux-foundation.org
> > @@ -16262,6 +16262,18 @@ F: include/uapi/linux/virtio_*.h
> > F: drivers/crypto/virtio/
> > F: mm/balloon_compaction.c
> >
> > +VIRTIO BLOCK AND SCSI DRIVERS
> > +M: "Michael S. Tsirkin" <mst@redhat.com>
> > +M: Paolo Bonzini <pbonzini@redhat.com>
> > +M: Stefan Hajnoczi <stefanha@redhat.com>
>
> Please make this R at least for me, so that it's clear that patches
> still flow through your and Jason's tree. Not sure if you want to keep
> Jason as M.
>
> Paolo
Not for block I think. He never reviews these.
> > +L: virtualization@lists.linux-foundation.org
> > +S: Maintained
> > +F: drivers/block/virtio_blk.c
> > +F: drivers/scsi/virtio_scsi.c
> > +F: include/uapi/linux/virtio_blk.h
> > +F: include/uapi/linux/virtio_scsi.h
> > +F: drivers/vhost/scsi.c
> > +
> > VIRTIO CRYPTO DRIVER
> > M: Gonglei <arei.gonglei@huawei.com>
> > L: virtualization@lists.linux-foundation.org
> >
^ permalink raw reply
* Re: [PATCH] MAiNTAINERS: add Paolo, Stefan for virtio blk/scsi
From: Stefan Hajnoczi @ 2019-03-27 16:57 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: pbonzini, virtualization
In-Reply-To: <20190327103254-mutt-send-email-mst@kernel.org>
[-- Attachment #1.1: Type: text/plain, Size: 573 bytes --]
On Wed, Mar 27, 2019 at 10:33:57AM -0400, Michael S. Tsirkin wrote:
> Jason doesn't really have the time to review blk/scsi
> patches. Paolo and Setfan agreed to help out.
>
> Thanks guys!
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>
> ---
There is relatively little activity in this area so I'd like to reply
with Reviewed-by/Acked-by on the mailing list and have patches merged
via your virtio tree. That way I do not maintain a sub-tree and send
you pull requests. Does this sound good?
Acked-by: Stefan Hajnoczi <stefanha@redhat.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH] MAiNTAINERS: add Paolo, Stefan for virtio blk/scsi
From: Paolo Bonzini @ 2019-03-27 17:01 UTC (permalink / raw)
To: Stefan Hajnoczi, Michael S. Tsirkin; +Cc: virtualization
In-Reply-To: <20190327165754.GF27283@stefanha-x1.localdomain>
[-- Attachment #1.1.1: Type: text/plain, Size: 811 bytes --]
On 27/03/19 17:57, Stefan Hajnoczi wrote:
> On Wed, Mar 27, 2019 at 10:33:57AM -0400, Michael S. Tsirkin wrote:
>> Jason doesn't really have the time to review blk/scsi
>> patches. Paolo and Setfan agreed to help out.
>>
>> Thanks guys!
>>
>> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
>>
>> ---
>
> There is relatively little activity in this area so I'd like to reply
> with Reviewed-by/Acked-by on the mailing list and have patches merged
> via your virtio tree. That way I do not maintain a sub-tree and send
> you pull requests. Does this sound good?
FWIW me too, that's why I suggested that Michael add us as reviewers
rather than maintainers. So,
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
too.
Paolo
> Acked-by: Stefan Hajnoczi <stefanha@redhat.com>
>
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
^ permalink raw reply
* Re: [PATCH] MAiNTAINERS: add Paolo, Stefan for virtio blk/scsi
From: Michael S. Tsirkin @ 2019-03-27 17:01 UTC (permalink / raw)
To: Stefan Hajnoczi; +Cc: pbonzini, virtualization
In-Reply-To: <20190327165754.GF27283@stefanha-x1.localdomain>
On Wed, Mar 27, 2019 at 04:57:54PM +0000, Stefan Hajnoczi wrote:
> On Wed, Mar 27, 2019 at 10:33:57AM -0400, Michael S. Tsirkin wrote:
> > Jason doesn't really have the time to review blk/scsi
> > patches. Paolo and Setfan agreed to help out.
> >
> > Thanks guys!
> >
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> >
> > ---
>
> There is relatively little activity in this area so I'd like to reply
> with Reviewed-by/Acked-by on the mailing list and have patches merged
> via your virtio tree. That way I do not maintain a sub-tree and send
> you pull requests. Does this sound good?
>
> Acked-by: Stefan Hajnoczi <stefanha@redhat.com>
v2 does that. pls ack that one then.
^ permalink raw reply
* Re: [PATCH net v3] failover: allow name change on IFF_UP slave interfaces
From: Michael S. Tsirkin @ 2019-03-27 22:16 UTC (permalink / raw)
To: si-wei liu
Cc: jiri, kubakici, sridhar.samudrala, alexander.duyck,
virtualization, liran.alon, netdev, boris.ostrovsky, davem
In-Reply-To: <f90d9dfa-f2f1-ff04-f3fe-88fa0deffdf7@oracle.com>
On Wed, Mar 27, 2019 at 01:10:10PM -0700, si-wei liu wrote:
> Another less safer option is that we just notify userspace anyway without
> sending down/up event around, as I don't see *any real application* cares
> about the link state or whatsoever when it attempts to detect rename.
How do you write a race ree handler then? ATM just detecting link up is
sufficient and covers 100% of cases. Seems like a good idea to keep it
that way.
--
MST
^ permalink raw reply
* [RFC PATCH 00/68] VFS: Convert a bunch of filesystems to the new mount API
From: David Howells @ 2019-03-27 23:40 UTC (permalink / raw)
To: viro
Cc: Sergey Senozhatsky, Rafael J. Wysocki, dri-devel, J. Bruce Fields,
ceph-devel, Mike Marshall, xen-devel, devel, Felipe Balbi,
Uma Krishnan, Manoj N. Kumar, Joel Becker, Trond Myklebust,
Mike Marciniszyn, Greg Kroah-Hartman, linux-usb, linux-kernel,
Arve Hjønnevåg, Frederic Barrat, Martin Brandenburg,
linux-ia64, David Airlie, virtualization
Hi Al,
Here's a set of patches that converts a bunch (but not yet all!) to the new
mount API. To this end, it makes the following changes:
(1) Provides a convenience member in struct fs_context that is OR'd into
sb->s_iflags by sget_fc().
(2) Provides a convenience helper function, vfs_init_pseudo_fs_context(),
for doing most of the work in mounting a pseudo filesystem.
(3) Provides a convenience helper function, vfs_get_block_super(), for
doing the work in setting up a block-based superblock.
(4) Improves the handling of fd-type parameters.
(5) Moves some of the subtype handling int fuse.
(6) Provides a convenience helper function, vfs_get_mtd_super(), for
doing the work in setting up an MTD device-based superblock.
(7) Kills off mount_pseudo(), mount_pseudo_xattr(), mount_ns(),
sget_userns(), mount_mtd(), mount_single().
(8) Converts a slew of filesystems to use the mount API.
(9) Fixes a bug in hypfs.
The patches can be found here also:
https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
on branch:
mount-api-viro
David
---
Andrew Price (1):
gfs2: Convert gfs2 to fs_context
David Howells (66):
vfs: Update mount API docs
vfs: Fix refcounting of filenames in fs_parser
vfs: Provide sb->s_iflags settings in fs_context struct
vfs: Provide a mount_pseudo-replacement for the new mount API
vfs: Convert aio to use the new mount API
vfs: Convert anon_inodes to use the new mount API
vfs: Convert bdev to use the new mount API
vfs: Convert nsfs to use the new mount API
vfs: Convert pipe to use the new mount API
vfs: Convert zsmalloc to use the new mount API
vfs: Convert sockfs to use the new mount API
vfs: Convert dax to use the new mount API
vfs: Convert drm to use the new mount API
vfs: Convert ia64 perfmon to use the new mount API
vfs: Convert cxl to use the new mount API
vfs: Convert ocxlflash to use the new mount API
vfs: Convert virtio_balloon to use the new mount API
vfs: Convert btrfs_test to use the new mount API
vfs: Kill off mount_pseudo() and mount_pseudo_xattr()
vfs: Use sget_fc() for pseudo-filesystems
vfs: Convert binderfs to use the new mount API
vfs: Convert nfsctl to use the new mount API
vfs: Convert rpc_pipefs to use the new mount API
vfs: Kill mount_ns()
vfs: Kill sget_userns()
vfs: Convert binfmt_misc to use the new mount API
vfs: Convert configfs to use the new mount API
vfs: Convert efivarfs to use the new mount API
vfs: Convert fusectl to use the new mount API
vfs: Convert qib_fs/ipathfs to use the new mount API
vfs: Convert ibmasmfs to use the new mount API
vfs: Convert oprofilefs to use the new mount API
vfs: Convert gadgetfs to use the new mount API
vfs: Convert xenfs to use the new mount API
vfs: Convert openpromfs to use the new mount API
vfs: Convert apparmorfs to use the new mount API
vfs: Convert securityfs to use the new mount API
vfs: Convert selinuxfs to use the new mount API
vfs: Convert smackfs to use the new mount API
vfs: Convert ramfs, shmem, tmpfs, devtmpfs, rootfs to use the new mount API
vfs: Create fs_context-aware mount_bdev() replacement
vfs: Make fs_parse() handle fs_param_is_fd-type params better
vfs: Convert fuse to use the new mount API
vfs: Move the subtype parameter into fuse
mtd: Provide fs_context-aware mount_mtd() replacement
vfs: Convert romfs to use the new mount API
vfs: Convert cramfs to use the new mount API
vfs: Convert jffs2 to use the new mount API
mtd: Kill mount_mtd()
vfs: Convert squashfs to use the new mount API
vfs: Convert ceph to use the new mount API
vfs: Convert functionfs to use the new mount API
vfs: Add a single-or-reconfig keying to vfs_get_super()
vfs: Convert debugfs to use the new mount API
vfs: Convert tracefs to use the new mount API
vfs: Convert pstore to use the new mount API
hypfs: Fix error number left in struct pointer member
vfs: Convert hypfs to use the new mount API
vfs: Convert spufs to use the new mount API
vfs: Kill mount_single()
vfs: Convert coda to use the new mount API
vfs: Convert autofs to use the new mount API
vfs: Convert devpts to use the new mount API
vfs: Convert bpf to use the new mount API
vfs: Convert ubifs to use the new mount API
vfs: Convert orangefs to use the new mount API
Masahiro Yamada (1):
kbuild: skip sub-make for in-tree build with GNU Make 4.x
Documentation/filesystems/mount_api.txt | 367 ++++++++-------
Documentation/filesystems/vfs.txt | 4
Makefile | 31 +
arch/ia64/kernel/perfmon.c | 14 -
arch/powerpc/platforms/cell/spufs/inode.c | 207 +++++----
arch/s390/hypfs/inode.c | 137 +++---
drivers/android/binderfs.c | 173 ++++---
drivers/base/devtmpfs.c | 16 -
drivers/block/rbd.c | 363 ++++++++-------
drivers/dax/super.c | 13 -
drivers/gpu/drm/drm_drv.c | 14 -
drivers/infiniband/hw/qib/qib_fs.c | 26 +
drivers/misc/cxl/api.c | 10
drivers/misc/ibmasm/ibmasmfs.c | 21 +
drivers/mtd/mtdcore.h | 1
drivers/mtd/mtdsuper.c | 181 ++++----
drivers/oprofile/oprofilefs.c | 20 +
drivers/scsi/cxlflash/ocxl_hw.c | 21 -
drivers/usb/gadget/function/f_fs.c | 233 +++++-----
drivers/usb/gadget/legacy/inode.c | 21 +
drivers/virtio/virtio_balloon.c | 19 -
drivers/xen/xenfs/super.c | 21 +
fs/aio.c | 15 -
fs/anon_inodes.c | 12
fs/autofs/autofs_i.h | 13 -
fs/autofs/init.c | 9
fs/autofs/inode.c | 429 ++++++++++--------
fs/binfmt_misc.c | 20 +
fs/block_dev.c | 14 -
fs/btrfs/tests/btrfs-tests.c | 13 -
fs/ceph/cache.c | 9
fs/ceph/cache.h | 5
fs/ceph/super.c | 697 ++++++++++++++---------------
fs/ceph/super.h | 1
fs/coda/inode.c | 171 +++++--
fs/configfs/mount.c | 20 +
fs/cramfs/inode.c | 69 ++-
fs/debugfs/inode.c | 186 ++++----
fs/devpts/inode.c | 265 +++++------
fs/efivarfs/super.c | 20 +
fs/fs_context.c | 16 -
fs/fs_parser.c | 18 +
fs/fuse/control.c | 20 +
fs/fuse/inode.c | 291 +++++++-----
fs/gfs2/incore.h | 8
fs/gfs2/ops_fstype.c | 495 ++++++++++++++++-----
fs/gfs2/super.c | 335 --------------
fs/gfs2/super.h | 3
fs/jffs2/fs.c | 21 -
fs/jffs2/os-linux.h | 4
fs/jffs2/super.c | 172 +++----
fs/libfs.c | 91 +++-
fs/nfsd/nfsctl.c | 33 +
fs/nsfs.c | 13 -
fs/openpromfs/inode.c | 20 +
fs/orangefs/orangefs-kernel.h | 8
fs/orangefs/orangefs-mod.c | 3
fs/orangefs/super.c | 186 ++++----
fs/pipe.c | 12
fs/pstore/inode.c | 109 +++--
fs/ramfs/inode.c | 104 +++-
fs/romfs/super.c | 46 +-
fs/squashfs/super.c | 100 ++--
fs/super.c | 301 ++++++-------
fs/tracefs/inode.c | 180 +++----
fs/ubifs/super.c | 447 ++++++++-----------
include/linux/ceph/ceph_debug.h | 1
include/linux/ceph/libceph.h | 17 +
include/linux/fs.h | 24 -
include/linux/fs_context.h | 20 +
include/linux/mtd/super.h | 6
include/linux/ramfs.h | 6
include/linux/shmem_fs.h | 4
init/do_mounts.c | 12
kernel/bpf/inode.c | 92 ++--
mm/shmem.c | 396 +++++++++++-----
mm/zsmalloc.c | 19 -
net/ceph/ceph_common.c | 410 +++++++----------
net/socket.c | 14 -
net/sunrpc/rpc_pipe.c | 34 +
security/apparmor/apparmorfs.c | 20 +
security/inode.c | 21 +
security/selinux/selinuxfs.c | 20 +
security/smack/smackfs.c | 34 +
84 files changed, 4257 insertions(+), 3810 deletions(-)
^ permalink raw reply
* [RFC PATCH 18/68] vfs: Convert virtio_balloon to use the new mount API
From: David Howells @ 2019-03-27 23:42 UTC (permalink / raw)
To: viro
Cc: Michael S. Tsirkin, linux-kernel, virtualization, dhowells,
linux-fsdevel
In-Reply-To: <155372999953.7602.13784796495137723805.stgit@warthog.procyon.org.uk>
Convert the virtio_balloon filesystem to the new internal mount API as the old
one will be obsoleted and removed. This allows greater flexibility in
communication of mount parameters between userspace, the VFS and the
filesystem.
See Documentation/filesystems/mount_api.txt for more information.
Signed-off-by: David Howells <dhowells@redhat.com>
cc: "Michael S. Tsirkin" <mst@redhat.com>
cc: Jason Wang <jasowang@redhat.com>
cc: virtualization@lists.linux-foundation.org
---
drivers/virtio/virtio_balloon.c | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index f19061b585a4..89d67c8aa719 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -757,21 +757,22 @@ static int virtballoon_migratepage(struct balloon_dev_info *vb_dev_info,
return MIGRATEPAGE_SUCCESS;
}
+#include <linux/fs_context.h>
-static struct dentry *balloon_mount(struct file_system_type *fs_type,
- int flags, const char *dev_name, void *data)
-{
- static const struct dentry_operations ops = {
- .d_dname = simple_dname,
- };
+static const struct dentry_operations balloon_dops = {
+ .d_dname = simple_dname,
+};
- return mount_pseudo(fs_type, "balloon-kvm:", NULL, &ops,
- BALLOON_KVM_MAGIC);
+static int balloon_init_fs_context(struct fs_context *fc)
+{
+ return vfs_init_pseudo_fs_context(fc, "balloon-kvm:",
+ NULL, NULL,
+ &balloon_dops, BALLOON_KVM_MAGIC);
}
static struct file_system_type balloon_fs = {
.name = "balloon-kvm",
- .mount = balloon_mount,
+ .init_fs_context = balloon_init_fs_context,
.kill_sb = kill_anon_super,
};
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox