On Monday, August 6, 2018 9:29 PM, Tetsuo Handa wrote:

On 2018/08/06 21:44, Wang, Wei W wrote:

quoted

On Monday, August 6, 2018 6:29 PM, Tetsuo Handa wrote:

quoted

On 2018/08/06 18:56, Wei Wang wrote:

quoted

On 08/03/2018 08:11 PM, Tetsuo Handa wrote:

quoted

On 2018/08/03 17:32, Wei Wang wrote:

quoted

+static int virtio_balloon_register_shrinker(struct virtio_balloon
+*vb) {
+    vb->shrinker.scan_objects = virtio_balloon_shrinker_scan;
+    vb->shrinker.count_objects = virtio_balloon_shrinker_count;
+    vb->shrinker.batch = 0;
+    vb->shrinker.seeks = DEFAULT_SEEKS;

Why flags field is not set? If vb is allocated by
kmalloc(GFP_KERNEL) and is nowhere zero-cleared, KASAN would

complain it.

quoted

quoted

quoted

Could you point where in the code that would complain it?
I only see two shrinker flags (NUMA_AWARE and MEMCG_AWARE), and

they seem not related to that.

Where is vb->shrinker.flags initialized?

Is that mandatory to be initialized?

Of course. ;-)

quoted

I find it's not initialized in most shrinkers (e.g. zs_register_shrinker,

huge_zero_page_shrinker).

Because most shrinkers are "statically initialized (which means that
unspecified fields are implicitly zero-cleared)" or "dynamically allocated with
__GFP_ZERO or zero-cleared using
memset() (which means that all fields are once zero-cleared)".

And if you once zero-clear vb at allocation time, you will get a bonus that
calling unregister_shrinker() without corresponding register_shrinker() is safe
(which will simplify initialization failure path).

Oh, I see, thanks. So it sounds better to directly kzalloc vb.

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