RE: [PATCH v2 0/2] virtio-balloon: some improvements

2018-07-27 Thread Wang, Wei W
On Friday, July 27, 2018 10:06 PM, Michael S. Tsirkin wrote:
> On Fri, Jul 27, 2018 at 05:24:53PM +0800, Wei Wang wrote:
> > This series is split from the "Virtio-balloon: support free page
> > reporting" series to make some improvements.
> >
> > v1->v2 ChangeLog:
> > - register the shrinker when VIRTIO_BALLOON_F_DEFLATE_ON_OOM is
> negotiated.
> >
> > Wei Wang (2):
> >   virtio-balloon: remove BUG() in init_vqs
> >   virtio_balloon: replace oom notifier with shrinker
> 
> Thanks!
> Given it's very late in the release cycle, I'll merge this for the next Linux
> release.

No problem. Thanks!

Best,
Wei
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


[PATCH] drm: qxl: Fix NULL pointer dereference at qxl_alloc_client_monitors_config

2018-07-27 Thread Anton Vasilyev
If qxl_alloc_client_monitors_config() fails to allocate
client_monitors_config then NULL pointer dereference occurs
in function qxl_display_copy_rom_client_monitors_config() after
qxl_alloc_client_monitors_config() call.

The patch adds return error from qxl_alloc_client_monitors_config()
and additional status for qxl_display_copy_rom_client_monitors_config
return value.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Anton Vasilyev 
---
Note: Is it correct that qxl_display_read_client_monitors_config() does not
return error in case of fail?
---
 drivers/gpu/drm/qxl/qxl_display.c | 16 +---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_display.c 
b/drivers/gpu/drm/qxl/qxl_display.c
index 768207fbbae3..a59b2eca5f5b 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -37,7 +37,8 @@ static bool qxl_head_enabled(struct qxl_head *head)
return head->width && head->height;
 }
 
-static void qxl_alloc_client_monitors_config(struct qxl_device *qdev, unsigned 
count)
+static int qxl_alloc_client_monitors_config(struct qxl_device *qdev,
+   unsigned int count)
 {
if (qdev->client_monitors_config &&
count > qdev->client_monitors_config->count) {
@@ -49,15 +50,17 @@ static void qxl_alloc_client_monitors_config(struct 
qxl_device *qdev, unsigned c
sizeof(struct qxl_monitors_config) +
sizeof(struct qxl_head) * count, GFP_KERNEL);
if (!qdev->client_monitors_config)
-   return;
+   return -ENOMEM;
}
qdev->client_monitors_config->count = count;
+   return 0;
 }
 
 enum {
MONITORS_CONFIG_MODIFIED,
MONITORS_CONFIG_UNCHANGED,
MONITORS_CONFIG_BAD_CRC,
+   MONITORS_CONFIG_ERROR,
 };
 
 static int qxl_display_copy_rom_client_monitors_config(struct qxl_device *qdev)
@@ -87,7 +90,10 @@ static int 
qxl_display_copy_rom_client_monitors_config(struct qxl_device *qdev)
  && (num_monitors != qdev->client_monitors_config->count)) {
status = MONITORS_CONFIG_MODIFIED;
}
-   qxl_alloc_client_monitors_config(qdev, num_monitors);
+   if (qxl_alloc_client_monitors_config(qdev, num_monitors)) {
+   status = MONITORS_CONFIG_ERROR;
+   return status;
+   }
/* we copy max from the client but it isn't used */
qdev->client_monitors_config->max_allowed =
qdev->monitors_config->max_allowed;
@@ -161,6 +167,10 @@ void qxl_display_read_client_monitors_config(struct 
qxl_device *qdev)
break;
udelay(5);
}
+   if (status == MONITORS_CONFIG_ERROR) {
+   DRM_DEBUG_KMS("ignoring client monitors config: error");
+   return;
+   }
if (status == MONITORS_CONFIG_BAD_CRC) {
DRM_DEBUG_KMS("ignoring client monitors config: bad crc");
return;
-- 
2.18.0

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


Re: [PATCH v2 0/2] virtio-balloon: some improvements

2018-07-27 Thread Michael S. Tsirkin
On Fri, Jul 27, 2018 at 05:24:53PM +0800, Wei Wang wrote:
> This series is split from the "Virtio-balloon: support free page
> reporting" series to make some improvements.
> 
> v1->v2 ChangeLog:
> - register the shrinker when VIRTIO_BALLOON_F_DEFLATE_ON_OOM is negotiated.
> 
> Wei Wang (2):
>   virtio-balloon: remove BUG() in init_vqs
>   virtio_balloon: replace oom notifier with shrinker

Thanks!
Given it's very late in the release cycle, I'll merge this for
the next Linux release.

>  drivers/virtio/virtio_balloon.c | 125 
> +++-
>  1 file changed, 72 insertions(+), 53 deletions(-)
> 
> -- 
> 2.7.4
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


Re: net-next boot error

2018-07-27 Thread Michael S. Tsirkin
On Thu, Jul 26, 2018 at 10:17:48AM -0400, Steven Rostedt wrote:
> 
> [ Added Thomas Gleixner ]
> 
> 
> On Thu, 26 Jul 2018 11:34:39 +0200
> Dmitry Vyukov  wrote:
> 
> > On Thu, Jul 26, 2018 at 11:29 AM, syzbot
> >  wrote:
> > > Hello,
> > >
> > > syzbot found the following crash on:
> > >
> > > HEAD commit:dc66fe43b7eb rds: send: Fix dead code in rds_sendmsg
> > > git tree:   net-next
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=127874c840
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=f34ce142a9f5f0e8
> > > dashboard link: 
> > > https://syzkaller.appspot.com/bug?extid=604f8271211546f5b3c7
> > > compiler:   gcc (GCC) 8.0.1 20180413 (experimental)
> > >
> > > Unfortunately, I don't have any reproducer for this crash yet.
> > >
> > > IMPORTANT: if you fix the bug, please add the following tag to the commit:
> > > Reported-by: syzbot+604f8271211546f5b...@syzkaller.appspotmail.com
> > >
> > > possible deadlock in static_key_slow_incsd 0:0:1:0: [sda] Attached SCSI 
> > > disk
> > > MACsec IEEE 802.1AE
> > > tun: Universal TUN/TAP device driver, 1.6
> > >
> > > 
> > > WARNING: possible recursive locking detected  
> > 
> > +Tetsuo, perhaps this boot lockdep problem then disables lockdep for
> > actual testing. I think lockdep should respect panic_on_warn.
> > 
> > 
> > > 4.18.0-rc6+ #141 Not tainted
> > > 
> > > swapper/0/1 is trying to acquire lock:
> > > (ptrval) (cpu_hotplug_lock.rw_sem){}, at:
> > > static_key_slow_inc+0x12/0x30 kernel/jump_label.c:124
> > >
> > > but task is already holding lock:
> > > (ptrval) (cpu_hotplug_lock.rw_sem){}, at: get_online_cpus
> > > include/linux/cpu.h:126 [inline]
> > > (ptrval) (cpu_hotplug_lock.rw_sem){}, at: 
> > > init_vqs+0xe1a/0x1520
> > > drivers/net/virtio_net.c:2777
> 
> Here init_vqs() does:
> 
>   get_online_cpus();
>   virtnet_set_affinity(vi);
>   put_online_cpus();
> 
> Which disables cpu hotplug and calls virtnet_set_affinity()
> 
> Note, get_online_cpus() is no longer recursive.
> 
> > >
> > > other info that might help us debug this:
> > >  Possible unsafe locking scenario:
> > >
> > >CPU0
> > >
> > >   lock(cpu_hotplug_lock.rw_sem);
> > >   lock(cpu_hotplug_lock.rw_sem);
> > >
> > >  *** DEADLOCK ***
> > >
> > >  May be due to missing lock nesting notation
> > >
> > > 3 locks held by swapper/0/1:
> > >  #0: (ptrval) (>mutex){}, at: device_lock
> > > include/linux/device.h:1134 [inline]
> > >  #0: (ptrval) (>mutex){}, at: __driver_attach+0x15f/0x2f0
> > > drivers/base/dd.c:820
> > >  #1: (ptrval) (cpu_hotplug_lock.rw_sem){}, at: get_online_cpus
> > > include/linux/cpu.h:126 [inline]
> > >  #1: (ptrval) (cpu_hotplug_lock.rw_sem){}, at:
> > > init_vqs+0xe1a/0x1520 drivers/net/virtio_net.c:2777
> > >  #2: (ptrval) (xps_map_mutex){+.+.}, at:
> > > __netif_set_xps_queue+0x243/0x23f0 net/core/dev.c:2278
> > >
> > > stack backtrace:
> > > CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.18.0-rc6+ #141
> > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> > > Google 01/01/2011
> > > Call Trace:
> > >  __dump_stack lib/dump_stack.c:77 [inline]
> > >  dump_stack+0x1c9/0x2b4 lib/dump_stack.c:113
> > >  print_deadlock_bug kernel/locking/lockdep.c:1765 [inline]
> > >  check_deadlock kernel/locking/lockdep.c:1809 [inline]
> > >  validate_chain kernel/locking/lockdep.c:2405 [inline]
> > >  __lock_acquire.cold.65+0x1fb/0x486 kernel/locking/lockdep.c:3435
> > >  lock_acquire+0x1e4/0x540 kernel/locking/lockdep.c:3924
> > >  percpu_down_read_preempt_disable include/linux/percpu-rwsem.h:36 [inline]
> > >  percpu_down_read include/linux/percpu-rwsem.h:59 [inline]
> > >  cpus_read_lock+0x43/0xa0 kernel/cpu.c:289
> > >  static_key_slow_inc+0x12/0x30 kernel/jump_label.c:124
> > >  __netif_set_xps_queue+0xaac/0x23f0 net/core/dev.c:2320
> 
> 
> __netif_set_xps_queue() calls static_key_slow_inc() which will also do
> a get_online_cpus() which will trigger this bug.
> 
> There's a static_key_slow_inc_cpuslocked() version that should be used
> when get_online_cpus() is already taken, but I see
> __netif_set_xps_queue() is called from several places, and I doubt it
> is always called with get_online_cpus() held. Thus just using the
> cpuslocked() version is probably not sufficient of a fix.
> 
> I don't know the code enough to offer other suggestions.
> 
> -- Steve

OK so the guess is it's due to combination of

commit 04157469b7b848f4a9978b63b1ea2ce62ad3a0a3
Author: Amritha Nambiar 
Date:   Fri Jun 29 21:26:46 2018 -0700

net: Use static_key for XPS maps
 
which uses static_key_slow_inc and

commit 8af2c06ff4b144064b51b7f688194474123d9c9c
Author: Amritha Nambiar 
Date:   Fri Jun 29 21:27:07 2018 -0700

net-sysfs: Add interface for Rx queue(s) map per Tx queue


which makes it all 

[PATCH] drm: qxl: Fix error handling at qxl_device_init

2018-07-27 Thread Anton Vasilyev
If qxl_device_init fails on creating resources and does not report it,
then qxl module will catch null pointer exception on remove, or on
probe's error path.

The patch adds error path with resources release into qxl_device_init.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Anton Vasilyev 
---
 drivers/gpu/drm/qxl/qxl_kms.c | 80 ---
 1 file changed, 73 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/qxl/qxl_kms.c b/drivers/gpu/drm/qxl/qxl_kms.c
index 771250aed78d..e25c589d5f50 100644
--- a/drivers/gpu/drm/qxl/qxl_kms.c
+++ b/drivers/gpu/drm/qxl/qxl_kms.c
@@ -102,8 +102,10 @@ int qxl_device_init(struct qxl_device *qdev,
int r, sb;
 
r = drm_dev_init(>ddev, drv, >dev);
-   if (r)
-   return r;
+   if (r) {
+   pr_err("Unable to init drm dev");
+   goto error;
+   }
 
qdev->ddev.pdev = pdev;
pci_set_drvdata(pdev, >ddev);
@@ -121,6 +123,11 @@ int qxl_device_init(struct qxl_device *qdev,
qdev->io_base = pci_resource_start(pdev, 3);
 
qdev->vram_mapping = io_mapping_create_wc(qdev->vram_base, 
pci_resource_len(pdev, 0));
+   if (!qdev->vram_mapping) {
+   pr_err("Unable to create vram_mapping");
+   r = -ENOMEM;
+   goto error;
+   }
 
if (pci_resource_len(pdev, 4) > 0) {
/* 64bit surface bar present */
@@ -139,6 +146,11 @@ int qxl_device_init(struct qxl_device *qdev,
qdev->surface_mapping =
io_mapping_create_wc(qdev->surfaceram_base,
 qdev->surfaceram_size);
+   if (!qdev->surface_mapping) {
+   pr_err("Unable to create surface_mapping");
+   r = -ENOMEM;
+   goto vram_mapping_free;
+   }
}
 
DRM_DEBUG_KMS("qxl: vram %llx-%llx(%dM %dk), surface %llx-%llx(%dM %dk, 
%s)\n",
@@ -155,20 +167,29 @@ int qxl_device_init(struct qxl_device *qdev,
qdev->rom = ioremap(qdev->rom_base, qdev->rom_size);
if (!qdev->rom) {
pr_err("Unable to ioremap ROM\n");
-   return -ENOMEM;
+   r = -ENOMEM;
+   goto surface_mapping_free;
}
 
-   qxl_check_device(qdev);
+   if (!qxl_check_device(qdev)) {
+   r = -ENODEV;
+   goto surface_mapping_free;
+   }
 
r = qxl_bo_init(qdev);
if (r) {
DRM_ERROR("bo init failed %d\n", r);
-   return r;
+   goto rom_unmap;
}
 
qdev->ram_header = ioremap(qdev->vram_base +
   qdev->rom->ram_header_offset,
   sizeof(*qdev->ram_header));
+   if (!qdev->ram_header) {
+   DRM_ERROR("Unable to ioremap RAM header\n");
+   r = -ENOMEM;
+   goto bo_fini;
+   }
 
qdev->command_ring = qxl_ring_create(&(qdev->ram_header->cmd_ring_hdr),
 sizeof(struct qxl_command),
@@ -176,6 +197,11 @@ int qxl_device_init(struct qxl_device *qdev,
 qdev->io_base + QXL_IO_NOTIFY_CMD,
 false,
 >display_event);
+   if (!qdev->command_ring) {
+   DRM_ERROR("Unable to create command ring\n");
+   r = -ENOMEM;
+   goto ram_header_unmap;
+   }
 
qdev->cursor_ring = qxl_ring_create(
&(qdev->ram_header->cursor_ring_hdr),
@@ -185,12 +211,23 @@ int qxl_device_init(struct qxl_device *qdev,
false,
>cursor_event);
 
+   if (!qdev->cursor_ring) {
+   DRM_ERROR("Unable to create cursor ring\n");
+   r = -ENOMEM;
+   goto command_ring_free;
+   }
+
qdev->release_ring = qxl_ring_create(
&(qdev->ram_header->release_ring_hdr),
sizeof(uint64_t),
QXL_RELEASE_RING_SIZE, 0, true,
NULL);
 
+   if (!qdev->release_ring) {
+   DRM_ERROR("Unable to create release ring\n");
+   r = -ENOMEM;
+   goto cursor_ring_free;
+   }
/* TODO - slot initialization should happen on reset. where is our
 * reset handler? */
qdev->n_mem_slots = qdev->rom->slots_end;
@@ -203,6 +240,12 @@ int qxl_device_init(struct qxl_device *qdev,
kmalloc_array(qdev->n_mem_slots, sizeof(struct qxl_memslot),
  GFP_KERNEL);
 
+   if (!qdev->mem_slots) {
+   DRM_ERROR("Unable to alloc mem slots\n");
+   r = -ENOMEM;
+   goto release_ring_free;

Re: [RFC 0/4] Virtio uses DMA API for all devices

2018-07-27 Thread Michael S. Tsirkin
On Wed, Jul 25, 2018 at 08:56:23AM +0530, Anshuman Khandual wrote:
> Results with and without the patches are similar.

Thanks! And another thing to try is virtio-net with
a fast NIC backend (40G and up). Unfortunately
at this point loopback tests stress the host
scheduler too much.

-- 
MST
___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


Re: [RFC 0/4] Virtio uses DMA API for all devices

2018-07-27 Thread Anshuman Khandual
On 07/27/2018 03:28 PM, Will Deacon wrote:
> Hi Anshuman,
> 
> On Fri, Jul 20, 2018 at 09:29:37AM +0530, Anshuman Khandual wrote:
>> This patch series is the follow up on the discussions we had before about
>> the RFC titled [RFC,V2] virtio: Add platform specific DMA API translation
>> for virito devices (https://patchwork.kernel.org/patch/10417371/). There
>> were suggestions about doing away with two different paths of transactions
>> with the host/QEMU, first being the direct GPA and the other being the DMA
>> API based translations.
>>
>> First patch attempts to create a direct GPA mapping based DMA operations
>> structure called 'virtio_direct_dma_ops' with exact same implementation
>> of the direct GPA path which virtio core currently has but just wrapped in
>> a DMA API format. Virtio core must use 'virtio_direct_dma_ops' instead of
>> the arch default in absence of VIRTIO_F_IOMMU_PLATFORM flag to preserve the
>> existing semantics. The second patch does exactly that inside the function
>> virtio_finalize_features(). The third patch removes the default direct GPA
>> path from virtio core forcing it to use DMA API callbacks for all devices.
>> Now with that change, every device must have a DMA operations structure
>> associated with it. The fourth patch adds an additional hook which gives
>> the platform an opportunity to do yet another override if required. This
>> platform hook can be used on POWER Ultravisor based protected guests to
>> load up SWIOTLB DMA callbacks to do the required (as discussed previously
>> in the above mentioned thread how host is allowed to access only parts of
>> the guest GPA range) bounce buffering into the shared memory for all I/O
>> scatter gather buffers to be consumed on the host side.
>>
>> Please go through these patches and review whether this approach broadly
>> makes sense. I will appreciate suggestions, inputs, comments regarding
>> the patches or the approach in general. Thank you.
> I just wanted to say that this patch series provides a means for us to
> force the coherent DMA ops for legacy virtio devices on arm64, which in turn
> means that we can enable the SMMU with legacy devices in our fastmodel
> emulation platform (which is slowly being upgraded to virtio 1.0) without
> hanging during boot. Patch below.
> 
> So:
> 
> Acked-by: Will Deacon 
> Tested-by: Will Deacon 

Thanks Will.

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


Re: [RFC 0/4] Virtio uses DMA API for all devices

2018-07-27 Thread Will Deacon
Hi Anshuman,

On Fri, Jul 20, 2018 at 09:29:37AM +0530, Anshuman Khandual wrote:
> This patch series is the follow up on the discussions we had before about
> the RFC titled [RFC,V2] virtio: Add platform specific DMA API translation
> for virito devices (https://patchwork.kernel.org/patch/10417371/). There
> were suggestions about doing away with two different paths of transactions
> with the host/QEMU, first being the direct GPA and the other being the DMA
> API based translations.
> 
> First patch attempts to create a direct GPA mapping based DMA operations
> structure called 'virtio_direct_dma_ops' with exact same implementation
> of the direct GPA path which virtio core currently has but just wrapped in
> a DMA API format. Virtio core must use 'virtio_direct_dma_ops' instead of
> the arch default in absence of VIRTIO_F_IOMMU_PLATFORM flag to preserve the
> existing semantics. The second patch does exactly that inside the function
> virtio_finalize_features(). The third patch removes the default direct GPA
> path from virtio core forcing it to use DMA API callbacks for all devices.
> Now with that change, every device must have a DMA operations structure
> associated with it. The fourth patch adds an additional hook which gives
> the platform an opportunity to do yet another override if required. This
> platform hook can be used on POWER Ultravisor based protected guests to
> load up SWIOTLB DMA callbacks to do the required (as discussed previously
> in the above mentioned thread how host is allowed to access only parts of
> the guest GPA range) bounce buffering into the shared memory for all I/O
> scatter gather buffers to be consumed on the host side.
> 
> Please go through these patches and review whether this approach broadly
> makes sense. I will appreciate suggestions, inputs, comments regarding
> the patches or the approach in general. Thank you.

I just wanted to say that this patch series provides a means for us to
force the coherent DMA ops for legacy virtio devices on arm64, which in turn
means that we can enable the SMMU with legacy devices in our fastmodel
emulation platform (which is slowly being upgraded to virtio 1.0) without
hanging during boot. Patch below.

So:

Acked-by: Will Deacon 
Tested-by: Will Deacon 

Thanks!

Will

--->8

>From 4ef39e9de2c87c97bf046816ca762832f92e39b5 Mon Sep 17 00:00:00 2001
From: Will Deacon 
Date: Fri, 27 Jul 2018 10:49:25 +0100
Subject: [PATCH] arm64: dma: Override DMA ops for legacy virtio devices

Virtio devices are always cache-coherent, so force use of the coherent
DMA ops for legacy virtio devices where the dma-coherent is known to
be omitted by QEMU for the MMIO transport.

Signed-off-by: Will Deacon 
---
 arch/arm64/include/asm/dma-mapping.h |  6 ++
 arch/arm64/mm/dma-mapping.c  | 19 +++
 2 files changed, 25 insertions(+)

diff --git a/arch/arm64/include/asm/dma-mapping.h 
b/arch/arm64/include/asm/dma-mapping.h
index b7847eb8a7bb..30aa8fb62dc3 100644
--- a/arch/arm64/include/asm/dma-mapping.h
+++ b/arch/arm64/include/asm/dma-mapping.h
@@ -44,6 +44,12 @@ void arch_teardown_dma_ops(struct device *dev);
 #define arch_teardown_dma_ops  arch_teardown_dma_ops
 #endif
 
+#ifdef CONFIG_VIRTIO
+struct virtio_device;
+void platform_override_dma_ops(struct virtio_device *vdev);
+#define platform_override_dma_ops  platform_override_dma_ops
+#endif
+
 /* do not use this function in a driver */
 static inline bool is_device_dma_coherent(struct device *dev)
 {
diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 61e93f0b5482..f9ca61b1b34d 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -891,3 +891,22 @@ void arch_setup_dma_ops(struct device *dev, u64 dma_base, 
u64 size,
}
 #endif
 }
+
+#ifdef CONFIG_VIRTIO
+#include 
+
+void platform_override_dma_ops(struct virtio_device *vdev)
+{
+   struct device *dev = vdev->dev.parent;
+   const struct dma_map_ops *dma_ops = _swiotlb_dma_ops;
+
+   if (virtio_has_feature(vdev, VIRTIO_F_VERSION_1))
+   return;
+
+   dev->archdata.dma_coherent = true;
+   if (iommu_get_domain_for_dev(dev))
+   dma_ops = _dma_ops;
+
+   set_dma_ops(dev, dma_ops);
+}
+#endif /* CONFIG_VIRTIO */
-- 
2.1.4

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


[PATCH v2 2/2] virtio_balloon: replace oom notifier with shrinker

2018-07-27 Thread Wei Wang
The OOM notifier is getting deprecated to use for the reasons mentioned
here by Michal Hocko: https://lkml.org/lkml/2018/7/12/314

This patch replaces the virtio-balloon oom notifier with a shrinker
to release balloon pages on memory pressure.

In addition, the bug in the replaced virtballoon_oom_notify that only
VIRTIO_BALLOON_ARRAY_PFNS_MAX (i.e 256) balloon pages can be freed
though the user has specified more than that number is fixed in the
shrinker_scan function.

Signed-off-by: Wei Wang 
Cc: Michael S. Tsirkin 
Cc: Michal Hocko 
Cc: Andrew Morton 
---
 drivers/virtio/virtio_balloon.c | 115 +++-
 1 file changed, 65 insertions(+), 50 deletions(-)

diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 9356a1a..6b2229b 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -27,7 +27,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -40,12 +39,12 @@
  */
 #define VIRTIO_BALLOON_PAGES_PER_PAGE (unsigned)(PAGE_SIZE >> 
VIRTIO_BALLOON_PFN_SHIFT)
 #define VIRTIO_BALLOON_ARRAY_PFNS_MAX 256
-#define OOM_VBALLOON_DEFAULT_PAGES 256
+#define DEFAULT_BALLOON_PAGES_TO_SHRINK 256
 #define VIRTBALLOON_OOM_NOTIFY_PRIORITY 80
 
-static int oom_pages = OOM_VBALLOON_DEFAULT_PAGES;
-module_param(oom_pages, int, S_IRUSR | S_IWUSR);
-MODULE_PARM_DESC(oom_pages, "pages to free on OOM");
+static unsigned long balloon_pages_to_shrink = DEFAULT_BALLOON_PAGES_TO_SHRINK;
+module_param(balloon_pages_to_shrink, ulong, 0600);
+MODULE_PARM_DESC(balloon_pages_to_shrink, "pages to free on memory presure");
 
 #ifdef CONFIG_BALLOON_COMPACTION
 static struct vfsmount *balloon_mnt;
@@ -86,8 +85,8 @@ struct virtio_balloon {
/* Memory statistics */
struct virtio_balloon_stat stats[VIRTIO_BALLOON_S_NR];
 
-   /* To register callback in oom notifier call chain */
-   struct notifier_block nb;
+   /* To register a shrinker to shrink memory upon memory pressure */
+   struct shrinker shrinker;
 };
 
 static struct virtio_device_id id_table[] = {
@@ -365,38 +364,6 @@ static void update_balloon_size(struct virtio_balloon *vb)
  );
 }
 
-/*
- * virtballoon_oom_notify - release pages when system is under severe
- * memory pressure (called from out_of_memory())
- * @self : notifier block struct
- * @dummy: not used
- * @parm : returned - number of freed pages
- *
- * The balancing of memory by use of the virtio balloon should not cause
- * the termination of processes while there are pages in the balloon.
- * If virtio balloon manages to release some memory, it will make the
- * system return and retry the allocation that forced the OOM killer
- * to run.
- */
-static int virtballoon_oom_notify(struct notifier_block *self,
- unsigned long dummy, void *parm)
-{
-   struct virtio_balloon *vb;
-   unsigned long *freed;
-   unsigned num_freed_pages;
-
-   vb = container_of(self, struct virtio_balloon, nb);
-   if (!virtio_has_feature(vb->vdev, VIRTIO_BALLOON_F_DEFLATE_ON_OOM))
-   return NOTIFY_OK;
-
-   freed = parm;
-   num_freed_pages = leak_balloon(vb, oom_pages);
-   update_balloon_size(vb);
-   *freed += num_freed_pages;
-
-   return NOTIFY_OK;
-}
-
 static void update_balloon_stats_func(struct work_struct *work)
 {
struct virtio_balloon *vb;
@@ -548,6 +515,54 @@ static struct file_system_type balloon_fs = {
 
 #endif /* CONFIG_BALLOON_COMPACTION */
 
+static unsigned long virtio_balloon_shrinker_scan(struct shrinker *shrinker,
+ struct shrink_control *sc)
+{
+   unsigned long pages_to_free = balloon_pages_to_shrink,
+ pages_freed = 0;
+   struct virtio_balloon *vb = container_of(shrinker,
+   struct virtio_balloon, shrinker);
+
+   /*
+* One invocation of leak_balloon can deflate at most
+* VIRTIO_BALLOON_ARRAY_PFNS_MAX balloon pages, so we call it
+* multiple times to deflate pages till reaching
+* balloon_pages_to_shrink pages.
+*/
+   while (vb->num_pages && pages_to_free) {
+   pages_to_free = balloon_pages_to_shrink - pages_freed;
+   pages_freed += leak_balloon(vb, pages_to_free);
+   }
+   update_balloon_size(vb);
+
+   return pages_freed / VIRTIO_BALLOON_PAGES_PER_PAGE;
+}
+
+static unsigned long virtio_balloon_shrinker_count(struct shrinker *shrinker,
+  struct shrink_control *sc)
+{
+   struct virtio_balloon *vb = container_of(shrinker,
+   struct virtio_balloon, shrinker);
+
+   return min_t(unsigned long, vb->num_pages, balloon_pages_to_shrink) /
+  VIRTIO_BALLOON_PAGES_PER_PAGE;
+}
+
+static void virtio_balloon_unregister_shrinker(struct 

[PATCH v2 1/2] virtio-balloon: remove BUG() in init_vqs

2018-07-27 Thread Wei Wang
It's a bit overkill to use BUG when failing to add an entry to the
stats_vq in init_vqs. So remove it and just return the error to the
caller to bail out nicely.

Signed-off-by: Wei Wang 
Cc: Michael S. Tsirkin 
---
 drivers/virtio/virtio_balloon.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 6b237e3..9356a1a 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -455,9 +455,13 @@ static int init_vqs(struct virtio_balloon *vb)
num_stats = update_balloon_stats(vb);
 
sg_init_one(, vb->stats, sizeof(vb->stats[0]) * num_stats);
-   if (virtqueue_add_outbuf(vb->stats_vq, , 1, vb, GFP_KERNEL)
-   < 0)
-   BUG();
+   err = virtqueue_add_outbuf(vb->stats_vq, , 1, vb,
+  GFP_KERNEL);
+   if (err) {
+   dev_warn(>vdev->dev, "%s: add stat_vq failed\n",
+__func__);
+   return err;
+   }
virtqueue_kick(vb->stats_vq);
}
return 0;
-- 
2.7.4

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


[PATCH v2 0/2] virtio-balloon: some improvements

2018-07-27 Thread Wei Wang
This series is split from the "Virtio-balloon: support free page
reporting" series to make some improvements.

v1->v2 ChangeLog:
- register the shrinker when VIRTIO_BALLOON_F_DEFLATE_ON_OOM is negotiated.

Wei Wang (2):
  virtio-balloon: remove BUG() in init_vqs
  virtio_balloon: replace oom notifier with shrinker

 drivers/virtio/virtio_balloon.c | 125 +++-
 1 file changed, 72 insertions(+), 53 deletions(-)

-- 
2.7.4

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization


IEEE Record # 41985: 2018 3rd International Conference on Contemporary Computing and Informatics (IC3I).

2018-07-27 Thread Dr. S K Niranjan Aradhya
*<< Apologies for cross-postings >><<< Please circulate among your friends,
peers and researchers >>>*

IEEE Conference Record No.: #41985;

2018 3rd International Conference on Contemporary Computing and Informatics
(IC3I).

Conference Date : 10 - 12 October 2018
Submission Deadline: 30 July 2018

*Submission Link:http://cmsweb.com.sg/ic3i18/index.php/ic3i18/ic3i18/login
*

IEEE ISBN : 978-1-5386-6894-8
IEEE Part No. : CFP18AWQ-ART

Selected, accepted and extended paper will be published in Scopus Indexed
International Journal of Forensic Software Engineering published by
InderScience

All accepted and presented papers will be submitted to the IEEE for
possible publication in IEEE Xplore Digital Library. Previous edition
indexed in: SCOPUS, ISI Web of Science, Engineering Index, Google, etc.

If you like to join the TPC or propose a special session or symposiums
please write to: secretar...@ic3i.org

General Chair(s)
IC3I  2018 Conference

--
Disclaimer: We have clearly mentioned the subject lines and your email
address won't be misleading in any form. We have found your mail address
through our own efforts on the web search and not through any illegal way.
If you wish to remove your information from our mailing list or no longer
receive future announcements, please email with REMOVE in subject. Your
request to opt-out will be effective within a reasonable amount of time.
 ic3i-cfp.pdf

___
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization