[Trusty/Utopic/Vivid][SRU][PATCH] LP#1456952 -- mm/slab_common: support the slub_debug boot option on specific object size

[Gavin Guo]

On Fri, May 22, 2015 at 8:49 PM, Tim Gardner <tim.gardner at canonical.com> wrote:
> On 05/22/2015 04:00 AM, Gavin Guo wrote:
>>
>> BugLink: http://bugs.launchpad.net/bugs/1456952
>>
>> [Impact]
>>
>> slub_debug cannot work for specific kmem_cache size.
>>
>> e.g. slub_debug=PU,kmalloc-1024
>>
>> The slub_debug is used to enable the debugging of use-after-free, poison
>> overwritten, double free. And it also increases the up time of the server
>> when the above mentioned errors happen instead of crashing immediately.
>>
>> However, currently, there exists bug that the slub_debug cannot be applied
>> for the specific object size. This is not helpful to enable the whole
>> system slub_debug because the performance loss will be up to 20%~30%
>> according to the customer's measurement. The patch here to limit the
>> slub_debug only on the specific object size to alleviate the performance
>> loss.
>>
>> [Fix]
>>
>> The slub_debug=PU,kmalloc-xx cannot work because in the
>> create_kmalloc_caches() the s->name is created after the
>> create_kmalloc_cache() is called.  The name is NULL in the
>> create_kmalloc_cache() so the kmem_cache_flags() would not set the
>> slub_debug flags to the s->flags.  The fix here set up a kmalloc_names
>> string array for the initialization purpose and delete the dynamic name
>> creation of kmalloc_caches.
>>
>> The patch generated from git format-patch from
>> Trusty/Utopic/Vivid/Upstream
>> can't be used for each other. So, I prepared 3 patches for each release.
>>
>> [Test case]
>>
>> Install the patched kernel.
>> sudo reboot
>>
>> sudo vim /etc/default/grub
>> append "slub_debug=FPZU,kmalloc-1024" to GRUB_CMDLINE_LINUX_DEFAULT
>> sudo update-grub
>> sudo reboot
>>
>> # Check if the kmalloc-1024 debug options are enabled
>> sudo cat /sys/kernel/slab/kmalloc-1024/sanity_checks
>> # shoulb be 1
>> sudo cat /sys/kernel/slab/kmalloc-1024/red_zone
>> # shoulb be 1
>> sudo cat /sys/kernel/slab/kmalloc-1024/poison
>> # shoulb be 1
>>
>> # Check other object size
>> sudo cat /sys/kernel/slab/kmalloc-8/sanity_checks
>> # shoulb be 0
>> sudo cat /sys/kernel/slab/kmalloc-8/red_zone
>> # shoulb be 0
>> sudo cat /sys/kernel/slab/kmalloc-8/poison
>> # shoulb be 0
>>
>> Gavin Guo (1):
>>    mm/slab_common: support the slub_debug boot option on specific object
>>      size
>>
>>   include/linux/slab.h | 22 +++++++++++++++++++
>>   mm/slab_common.c     | 62
>> +++++++++++++++++++++++++++++++++-------------------
>>   2 files changed, 61 insertions(+), 23 deletions(-)
>>
>
> This patch seems more like a debug _feature_, and not really a bug fix. Is
> that appropriate for an SRU ? Even though it should be benign, I would
> prefer to wait until it has been merged upstream.
>
> --
> Tim Gardner tim.gardner at canonical.com

Actually, it's a bug fix. The document in Documentation/vm/slub.txt specify
to apply slub_debug on specific object size:

slub_debug=<Debug-Options>,<slab name>
                                Enable options only for select slabs

But it cannot work currently.

I'll resend the SRU after the patche is applied on the upstream.