Re: [PATCH] of: reserved_mem: disable kmemleak scan on removed memory blocks
On 3/4/2019 4:04 PM, Nicolas Boichat wrote: On Wed, Feb 13, 2019 at 4:56 PM Nicolas Boichat wrote: On Tue, Jan 22, 2019 at 4:46 PM Prateek Patel wrote: On 11/10/2018 2:58 AM, Rob Herring wrote: On Fri, Nov 9, 2018 at 1:09 AM Prateek Patel wrote: From: Sri Krishna chowdary Memory reserved with "nomap" DT property in of_reserved_mem.c removes the memory block. The removed memory blocks don't have VA to PA mapping created in kernel page table. Kmemleak scan on removed memory blocks is causing page faults and leading to kernel panic. So, Disable kmemleak scan on the removed memory blocks. Following is the observed crash log: [ 154.846370] Unable to handle kernel paging request at virtual address ffc070a0 <1>[ 154.846576] Mem abort info: <1>[ 154.846635] Exception class = DABT (current EL), IL = 32 bits <1>[ 154.846737] SET = 0, FnV = 0 <1>[ 154.846796] EA = 0, S1PTW = 0 <1>[ 154.846859] Data abort info: <1>[ 154.846913] ISV = 0, ISS = 0x0006 <1>[ 154.846983] CM = 0, WnR = 0 <1>[ 154.847053] swapper pgtable: 4k pages, 39-bit VAs, pgd = ff8009df7000 <1>[ 154.847228] [ffc070a0] *pgd=00087fff5803, *pud=00087fff5803, *pmd= <0>[ 154.847408] Internal error: Oops: 9606 [#1] PREEMPT SMP <4>[ 154.847511] Modules linked in: nvs_led_test nvs_bmi160 nvs_cm3218 nvs_bh1730fvc nvi_bmpX80 nvi_ak89xx nvi_mpu cdc_acm uas lr388k7_ts imx268 imx318 imx204 imx274 imx185 lc898212 ov23850 ov10823 ov9281 ov5693 tc358840 pca9570 nvs snd_soc_tegra_machine_driver_mobile lp855x_bl spidev input_cfboost pwm_tegra tegra_cryptodev tegra_se_nvhost tegra_se_elp tegra_se ghash_ce sha2_ce sha1_ce aes_ce_ccm cryptd nvgpu cpufreq_userspace snd_soc_tegra186_alt_dspk snd_soc_tegra186_alt_asrc snd_soc_tegra186_alt_arad snd_soc_tegra210_alt_ope snd_soc_tegra210_alt_mvc snd_soc_tegra210_alt_dmic snd_soc_tegra210_alt_amx snd_soc_tegra210_alt_adx snd_soc_tegra210_alt_afc snd_soc_tegra210_alt_mixer snd_soc_tegra210_alt_i2s snd_soc_tegra210_alt_sfc snd_soc_tegra210_alt_adsp snd_soc_tegra210_alt_admaif snd_soc_tegra210_alt_xbar <4>[ 154.882606] snd_soc_tegra_alt_utils snd_hda_tegra <4>[ 154.888133] CPU: 2 PID: 8079 Comm: sh Not tainted 4.14.53-tegra-05132-g9c33465 #2 <4>[ 154.895983] Hardware name: e3360_1099 (DT) <4>[ 154.900447] task: ffc7d62dda00 task.stack: ff800e2b <4>[ 154.906502] PC is at scan_block+0x7c/0x148 <4>[ 154.911234] LR is at scan_block+0x78/0x148 <4>[ 154.915689] pc : [] lr : [] pstate: 804000c9 <4>[ 154.923290] sp : ff800e2b3b80 <4>[ 154.927228] x29: ff800e2b3b80 x28: ffc7d62dda00 <4>[ 154.932999] x27: ff8009aaa000 x26: ffc070c0 <4>[ 154.938769] x25: 00c0 x24: ff8009d90608 <4>[ 154.944287] x23: ffc7dc6c6000 x22: ff8009d9 <4>[ 154.950320] x21: ff8009aeb320 x20: ffc070a00ff9 <4>[ 154.955919] x19: ffc070a0 x18: bec4c3f2 <4>[ 154.961438] x17: 002224777924 x16: ff80080bb0e0 <4>[ 154.967124] x15: x14: 0f75 <4>[ 154.973069] x13: 000f x12: ffbf1e9f4240 <4>[ 154.978670] x11: 0040 x10: 0ad0 <4>[ 154.984107] x9 : ff800e2b3ab0 x8 : ffc7d62de530 <4>[ 154.989958] x7 : 00078000 x6 : 0018 <4>[ 154.995645] x5 : x4 : <4>[ 155.001245] x3 : ff8009aaa000 x2 : 0047f6712000 <4>[ 155.006846] x1 : ffc7d1ae6900 x0 : [snip] For reference, there is another patch series that fixes the problem, by Mike Rapoport (https://lore.kernel.org/patchwork/patch/1041790/), already in linux-next (through mmotm): 42c9c0ac24393c of: fix kmemleak crash caused by imbalance in early memory reservation 48ec6d51f7d3f2 of: fix parameters order for call to memblock_find_in_range() If anyone is interested, I backported these patch to our 4.19 tree here, and they fix the issue: https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1496707 https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/1496708 Thanks, Thanks Nicolas for the reference, My acked-by is already present in the patch (https://lore.kernel.org/patchwork/patch/1041790/)
Re: [PATCH] selinux: avc: mark avc node as not a leak
On 1/9/2019 5:01 PM, Catalin Marinas wrote: Hi Prateek, On Wed, Jan 09, 2019 at 02:09:22PM +0530, Prateek Patel wrote: From: Sri Krishna chowdary kmemleak detects allocated objects as leaks if not accessed for default scan time. The memory allocated using avc_alloc_node is freed using rcu mechanism when nodes are reclaimed or on avc_flush. So, there is no real leak here and kmemleak_scan detects it as a leak which is false positive. Hence, mark it as kmemleak_not_leak. In theory, kmemleak should detect the node->rhead in the lists used by call_rcu() and not report it as a leak. Which RCU options do you have enabled (just to check whether kmemleak tracks the RCU internal lists)? Also, does this leak eventually disappear without your patch? Does echo dump=0xffc0dd1a0e60 > /sys/kernel/debug/kmemleak still display this object? Thanks. Hi Catalin, It was intermittently showing leak and didn't repro on multiple runs. To repo, I decreased the minimum object age for reporting, I found triggering the second scan just after first is not showing any leak. Also, without my patch, on echo dump, obj is not displaying. Is increasing minimum object age for reporting a good idea to handle such type of issues to avoid false-positives? Following is the log: t186_int:/ # echo scan > /sys/kernel/debug/kmemleak t186_int:/ # cat /sys/kernel/debug/kmemleak unreferenced object 0xffc1e06424c8 (size 72): comm "netd", pid 4891, jiffies 4294906431 (age 23.120s) hex dump (first 32 bytes): 97 01 00 00 1b 00 00 00 0b 00 00 00 57 06 04 00 W... 00 00 00 00 ff ff ff ff 01 00 00 00 00 00 00 00 backtrace: [] kmem_cache_alloc+0x1ac/0x2c0 [] avc_alloc_node+0x28/0x240 [] avc_compute_av+0xa4/0x1d0 [] avc_has_perm+0xf8/0x1b8 [] file_has_perm+0xb8/0xe8 [] match_file+0x44/0x98 [] iterate_fd+0x84/0xd0 [] selinux_bprm_committing_creds+0xec/0x230 [] security_bprm_committing_creds+0x44/0x60 [] install_exec_creds+0x20/0x70 [] load_elf_binary+0x31c/0xd10 [] search_binary_handler+0x98/0x288 [] do_execveat_common.isra.14+0x550/0x6d0 [] SyS_execve+0x4c/0x60 [] el0_svc_naked+0x34/0x38 [] 0x unreferenced object 0xffc1ab3c61b0 (size 72): comm "crash_dump64", pid 5058, jiffies 4294907834 (age 17.508s) hex dump (first 32 bytes): 2f 02 00 00 6b 00 00 00 07 00 00 00 53 04 04 00 /...k...S... 00 00 00 00 ff ff fd ff 01 00 00 00 00 00 00 00 backtrace: [] kmem_cache_alloc+0x1ac/0x2c0 [] avc_alloc_node+0x28/0x240 [] avc_compute_av+0xa4/0x1d0 [] avc_has_perm_noaudit+0xe4/0x120 [] selinux_inode_permission+0xc4/0x1c8 [] security_inode_permission+0x60/0x88 [] __inode_permission2+0x54/0x120 [] inode_permission2+0x38/0x80 [] may_open+0x70/0x128 [] do_last+0x234/0xee8 [] path_openat+0xa8/0x310 [] do_filp_open+0x88/0x108 [] do_sys_open+0x1a4/0x290 [] SyS_openat+0x3c/0x50 [] el0_svc_naked+0x34/0x38 [] 0x unreferenced object 0xffc1d3bcf678 (size 72): comm "mediaserver", pid 5156, jiffies 4294909577 (age 10.536s) hex dump (first 32 bytes): 0b 02 00 00 e2 01 00 00 07 00 00 00 53 04 04 00 S... 00 00 00 00 f7 ff ff ff 01 00 00 00 00 00 00 00 backtrace: [] kmem_cache_alloc+0x1ac/0x2c0 [] avc_alloc_node+0x28/0x240 [] avc_compute_av+0xa4/0x1d0 [] avc_has_perm_noaudit+0xe4/0x120 [] selinux_inode_permission+0xc4/0x1c8 [] security_inode_permission+0x60/0x88 [] __inode_permission2+0x54/0x120 [] inode_permission2+0x38/0x80 [] may_open+0x70/0x128 [] do_last+0x234/0xee8 [] path_openat+0xa8/0x310 [] do_filp_open+0x88/0x108 [] do_sys_open+0x1a4/0x290 [] compat_SyS_openat+0x3c/0x50 [] el0_svc_naked+0x34/0x38 [] 0x t186_int:/ # echo dump=0xffc1d3bcf678 > /sys/kernel/debug/kmemleak kmemleak: Unknown object at 0xffc1d3bcf678 Thanks,
Re: kmemleak panic
On 1/23/2019 11:24 AM, Mike Rapoport wrote:
On Tue, Jan 22, 2019 at 03:12:54PM +0100, Marc Gonzalez wrote:
On 22/01/2019 15:02, Marc Gonzalez wrote:
On 21/01/2019 18:42, Mike Rapoport wrote:
If I understood correctly, the trouble comes from no-map range allocated in
early_init_dt_alloc_reserved_memory_arch().
There's indeed imbalance, because memblock_alloc() does kmemleak_alloc(), but
memblock_remove() does not do kmemleak_free().
I think the best way is to replace __memblock_alloc_base() with
memblock_find_in_range(), e.g something like:
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 1977ee0adcb1..6807a1cffe55 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -37,21 +37,16 @@ int __init __weak
early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
*/
end = !end ? MEMBLOCK_ALLOC_ANYWHERE : end;
align = !align ? SMP_CACHE_BYTES : align;
- base = __memblock_alloc_base(size, align, end);
+ base = memblock_find_in_range(size, align, start, end);
if (!base)
return -ENOMEM;
- /*
-* Check if the allocated region fits in to start..end window
-*/
- if (base < start) {
- memblock_free(base, size);
- return -ENOMEM;
- }
-
*res_base = base;
if (nomap)
return memblock_remove(base, size);
+ else
+ return memblock_reserve(base, size);
+
return 0;
}
Your patch solves the issue. \o/
Great :)
[ Add nvidia devs, but drop schowd...@nvidia.com ]
Resending it as a formal patch now, I took a liberty to add your Tested-by.
From a847ca684db29a3c09e4dd2a8a008b35cf36e52f Mon Sep 17 00:00:00 2001
From: Mike Rapoport
Date: Wed, 23 Jan 2019 07:38:50 +0200
Subject: [PATCH] of: fix kmemleak crash caused by imbalance in early memory
reservation
Marc Gonzalez reported the following kmemleak crash:
Unable to handle kernel paging request at virtual address ffc021e0
Mem abort info:
ESR = 0x9606
Exception class = DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x0006
CM = 0, WnR = 0
swapper pgtable: 4k pages, 39-bit VAs, pgdp = (ptrval)
[ffc021e0] pgd=00017e3ba803, pud=00017e3ba803,
pmd=
Internal error: Oops: 9606 [#1] PREEMPT SMP
Modules linked in:
CPU: 6 PID: 523 Comm: kmemleak Tainted: G S W 5.0.0-rc1 #13
Hardware name: Qualcomm Technologies, Inc. MSM8998 v1 MTP (DT)
pstate: 8085 (Nzcv daIf -PAN -UAO)
pc : scan_block+0x70/0x190
lr : scan_block+0x6c/0x190
sp : ff8012e8bd20
x29: ff8012e8bd20 x28: ffc0fdbaf018
x27: ffc02200 x26: 0080
x25: ff8011aadf70 x24: ffc0f8cc8000
x23: ff8010dc8000 x22: ff8010dc8830
x21: ffc021e00ff9 x20: ffc0f8cc8050
x19: ffc021e0 x18: 2409
x17: 0200 x16:
x15: ff8010e14dd8 x14: 2406
x13: 4c4dd0c6 x12: ffc0f77dad58
x11: 0001 x10: ff8010d9e688
x9 : ff8010d9f000 x8 : ff8010d9e688
x7 : 0002 x6 :
x5 : ff8011511c20 x4 : 26d1
x3 : ff8010e14d88 x2 : 5b36396f4e7d4000
x1 : 00208040 x0 :
Process kmemleak (pid: 523, stack limit = 0x(ptrval))
Call trace:
scan_block+0x70/0x190
scan_gray_list+0x108/0x1c0
kmemleak_scan+0x33c/0x7c0
kmemleak_scan_thread+0x98/0xf0
kthread+0x11c/0x120
ret_from_fork+0x10/0x1c
Code: f9000fb4 d503201f 97d2 35000580 (f9400260)
---[ end trace 176d6ed9d86a0c33 ]---
note: kmemleak[523] exited with preempt_count 2
The crash happens when a no-map area is allocated in
early_init_dt_alloc_reserved_memory_arch(). The allocated region is
registered with kmemleak, but it is then removed from memblock using
memblock_remove() that is not kmemleak-aware.
Replacing __memblock_alloc_base() with memblock_find_in_range() makes sure
that the allocated memory is not added to kmemleak and then
memblock_remove()'ing this memory is safe.
As a bonus, since memblock_find_in_range() ensures the allocation in the
specified range, the bounds check can be removed.
Signed-off-by: Mike Rapoport
Tested-by: Marc Gonzalez
---
drivers/of/of_reserved_mem.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 1977ee0adcb1..6807a1cffe55 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -37,21 +37,16 @@ int __init __weak
early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
*/
end = !end ? MEMBLOCK_ALLOC_ANYWHERE : end;
align = !align ? SMP_CACHE_BYTES : align;
- base = __memblock_alloc_base(size, align, end);
+ base = memblock_find_in_range(size, align, start, end);
if (!base)
Re: [PATCH] of: reserved_mem: disable kmemleak scan on removed memory blocks
On 11/10/2018 2:58 AM, Rob Herring wrote:
On Fri, Nov 9, 2018 at 1:09 AM Prateek Patel wrote:
From: Sri Krishna chowdary
Memory reserved with "nomap" DT property in of_reserved_mem.c
removes the memory block. The removed memory blocks don't have
VA to PA mapping created in kernel page table. Kmemleak scan on
removed memory blocks is causing page faults and leading to
kernel panic. So, Disable kmemleak scan on the removed memory
blocks.
Following is the observed crash log:
[ 154.846370] Unable to handle kernel paging request at virtual address
ffc070a0
<1>[ 154.846576] Mem abort info:
<1>[ 154.846635] Exception class = DABT (current EL), IL = 32 bits
<1>[ 154.846737] SET = 0, FnV = 0
<1>[ 154.846796] EA = 0, S1PTW = 0
<1>[ 154.846859] Data abort info:
<1>[ 154.846913] ISV = 0, ISS = 0x0006
<1>[ 154.846983] CM = 0, WnR = 0
<1>[ 154.847053] swapper pgtable: 4k pages, 39-bit VAs, pgd = ff8009df7000
<1>[ 154.847228] [ffc070a0] *pgd=00087fff5803,
*pud=00087fff5803, *pmd=
<0>[ 154.847408] Internal error: Oops: 9606 [#1] PREEMPT SMP
<4>[ 154.847511] Modules linked in: nvs_led_test nvs_bmi160 nvs_cm3218
nvs_bh1730fvc nvi_bmpX80 nvi_ak89xx nvi_mpu cdc_acm uas lr388k7_ts imx268 imx318
imx204 imx274 imx185 lc898212 ov23850 ov10823 ov9281 ov5693 tc358840 pca9570 nvs
snd_soc_tegra_machine_driver_mobile lp855x_bl spidev input_cfboost pwm_tegra
tegra_cryptodev tegra_se_nvhost tegra_se_elp tegra_se ghash_ce sha2_ce sha1_ce
aes_ce_ccm cryptd nvgpu cpufreq_userspace snd_soc_tegra186_alt_dspk
snd_soc_tegra186_alt_asrc snd_soc_tegra186_alt_arad snd_soc_tegra210_alt_ope
snd_soc_tegra210_alt_mvc snd_soc_tegra210_alt_dmic snd_soc_tegra210_alt_amx
snd_soc_tegra210_alt_adx snd_soc_tegra210_alt_afc snd_soc_tegra210_alt_mixer
snd_soc_tegra210_alt_i2s snd_soc_tegra210_alt_sfc snd_soc_tegra210_alt_adsp
snd_soc_tegra210_alt_admaif snd_soc_tegra210_alt_xbar
<4>[ 154.882606] snd_soc_tegra_alt_utils snd_hda_tegra
<4>[ 154.888133] CPU: 2 PID: 8079 Comm: sh Not tainted
4.14.53-tegra-05132-g9c33465 #2
<4>[ 154.895983] Hardware name: e3360_1099 (DT)
<4>[ 154.900447] task: ffc7d62dda00 task.stack: ff800e2b
<4>[ 154.906502] PC is at scan_block+0x7c/0x148
<4>[ 154.911234] LR is at scan_block+0x78/0x148
<4>[ 154.915689] pc : [] lr : [] pstate:
804000c9
<4>[ 154.923290] sp : ff800e2b3b80
<4>[ 154.927228] x29: ff800e2b3b80 x28: ffc7d62dda00
<4>[ 154.932999] x27: ff8009aaa000 x26: ffc070c0
<4>[ 154.938769] x25: 00c0 x24: ff8009d90608
<4>[ 154.944287] x23: ffc7dc6c6000 x22: ff8009d9
<4>[ 154.950320] x21: ff8009aeb320 x20: ffc070a00ff9
<4>[ 154.955919] x19: ffc070a0 x18: bec4c3f2
<4>[ 154.961438] x17: 002224777924 x16: ff80080bb0e0
<4>[ 154.967124] x15: x14: 0f75
<4>[ 154.973069] x13: 000f x12: ffbf1e9f4240
<4>[ 154.978670] x11: 0040 x10: 0ad0
<4>[ 154.984107] x9 : ff800e2b3ab0 x8 : ffc7d62de530
<4>[ 154.989958] x7 : 00078000 x6 : 0018
<4>[ 154.995645] x5 : x4 :
<4>[ 155.001245] x3 : ff8009aaa000 x2 : 0047f6712000
<4>[ 155.006846] x1 : ffc7d1ae6900 x0 :
Signed-off-by: Sri Krishna chowdary
Signed-off-by: Prateek
---
drivers/of/of_reserved_mem.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 1977ee0..ac8f377 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#define MAX_RESERVED_REGIONS 32
static struct reserved_mem reserved_mem[MAX_RESERVED_REGIONS];
@@ -50,8 +51,10 @@ int __init __weak
early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
}
*res_base = base;
- if (nomap)
+ if (nomap) {
+ kmemleak_no_scan(__va(base));
return memblock_remove(base, size);
I'm curious how I can't find any other similar example in the kernel.
Please Cc some kmemleak folks.
Perhaps we should be using memblock_mark_nomap() for nomap areas?
Rob
Sorry for this late reply.
Yes, memblock_mark_nomap() can be used here but if I understand
correctly, memblock_mark_nomap() is used to indicate marked parts of
memory should not be covered by the kernel direct mapping and
memblock_remove() here is doing that by removing a given memory from the
"memblock.memory" list to prevent the memory from CPU accessing by the
linear address. I am not 100% sure what will be the side effects of
using memblock_mark_nomap(). Adding folks to
Re: kmemleak panic
On 1/21/2019 7:24 PM, Marc Gonzalez wrote: On 21/01/2019 14:35, Rob Herring wrote: On Mon, Jan 21, 2019 at 6:19 AM Robin Murphy wrote: On 21/01/2019 11:57, Marc Gonzalez wrote: [...] # echo dump=0xffc021e0 > /sys/kernel/debug/kmemleak kmemleak: Object 0xffc021e0 (size 2097152): kmemleak: comm "swapper/0", pid 0, jiffies 4294892296 kmemleak: min_count = 0 kmemleak: count = 0 kmemleak: flags = 0x1 kmemleak: checksum = 0 kmemleak: backtrace: kmemleak_alloc_phys+0x48/0x60 memblock_alloc_range_nid+0x8c/0xa4 memblock_alloc_base_nid+0x4c/0x60 __memblock_alloc_base+0x3c/0x4c early_init_dt_alloc_reserved_memory_arch+0x54/0xa4 fdt_init_reserved_mem+0x308/0x3ec early_init_fdt_scan_reserved_mem+0x88/0xb0 arm64_memblock_init+0x1dc/0x254 setup_arch+0x1c8/0x4ec start_kernel+0x84/0x44c 0x OK, so via the __va(phys) call in kmemleak_alloc_phys(), you end up with the linear map address of a no-map reservation, which unsurprisingly turns out not to be mapped. Is there a way to tell kmemleak that it can't scan within a particular object? Yes, kmemleak_no_scan() do this which is done in patch https://patchwork.ozlabs.org/patch/995367/ This was done to avoid kmemleak scanning on the blocks which are nomaped and should not have linear mapping created in kernel page table. There was this patch posted[1]. I never got a reply, so it hasn't been applied. Rob https://patchwork.ozlabs.org/patch/995367/ It is worth noting that the author's email address appears to be dead. : host hqemgate08.nvidia.com[216.228.121.117] said: 550 #5.1.0 Address rejected. (in reply to RCPT TO command) Adding a few nvidia devs for comment.
[PATCH] selinux: avc: mark avc node as not a leak
From: Sri Krishna chowdary kmemleak detects allocated objects as leaks if not accessed for default scan time. The memory allocated using avc_alloc_node is freed using rcu mechanism when nodes are reclaimed or on avc_flush. So, there is no real leak here and kmemleak_scan detects it as a leak which is false positive. Hence, mark it as kmemleak_not_leak. Following is the log for avc_alloc_node detected as leak: unreferenced object 0xffc0dd1a0e60 (size 64): comm "InputDispatcher", pid 648, jiffies 4294944629 (age 698.180s) hex dump (first 32 bytes): ed 00 00 00 ed 00 00 00 17 00 00 00 3f fe 41 00 ?.A. 00 00 00 00 ff ff ff ff 01 00 00 00 00 00 00 00 backtrace: [] __save_stack_trace+0x24/0x34 [] create_object+0x13c/0x290 [] kmemleak_alloc+0x80/0xbc [] kmem_cache_alloc+0x128/0x1f8 [] avc_alloc_node+0x2c/0x1e8 [] avc_insert+0x38/0x13c [] avc_compute_av+0x4c/0x60 [] avc_has_perm_flags+0x90/0x188 [] sock_has_perm+0x84/0x98 [] selinux_socket_sendmsg+0x1c/0x28 [] security_socket_sendmsg+0x14/0x20 [] sock_sendmsg+0x70/0xc8 [] SyS_sendto+0x140/0x1ec [] el0_svc_naked+0x34/0x38 [] 0x Signed-off-by: Sri Krishna chowdary Signed-off-by: Prateek --- security/selinux/avc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/security/selinux/avc.c b/security/selinux/avc.c index 635e5c1..ecfd0cd 100644 --- a/security/selinux/avc.c +++ b/security/selinux/avc.c @@ -30,6 +30,7 @@ #include #include #include +#include #include "avc.h" #include "avc_ss.h" #include "classmap.h" @@ -573,6 +574,7 @@ static struct avc_node *avc_alloc_node(struct selinux_avc *avc) if (!node) goto out; + kmemleak_not_leak(node); INIT_HLIST_NODE(>list); avc_cache_stats_incr(allocations); -- 2.7.4
Re: [PATCH V2] kmemleak: Add config to select auto scan
Hi Catalin, Can you mark this patch as acknowledged so that it can be picked up by the maintainer. Adding Andrew. Thanks, On 10/29/2018 4:13 PM, Catalin Marinas wrote: On Mon, Oct 22, 2018 at 11:38:43PM +0530, Prateek Patel wrote: From: Sri Krishna chowdary Kmemleak scan can be cpu intensive and can stall user tasks at times. To prevent this, add config DEBUG_KMEMLEAK_AUTO_SCAN to enable/disable auto scan on boot up. Also protect first_run with DEBUG_KMEMLEAK_AUTO_SCAN as this is meant for only first automatic scan. Signed-off-by: Sri Krishna chowdary Signed-off-by: Sachin Nikam Signed-off-by: Prateek Looks fine to me. Reviewed-by: Catalin Marinas
[PATCH] of: reserved_mem: disable kmemleak scan on removed memory blocks
From: Sri Krishna chowdary
Memory reserved with "nomap" DT property in of_reserved_mem.c
removes the memory block. The removed memory blocks don't have
VA to PA mapping created in kernel page table. Kmemleak scan on
removed memory blocks is causing page faults and leading to
kernel panic. So, Disable kmemleak scan on the removed memory
blocks.
Following is the observed crash log:
[ 154.846370] Unable to handle kernel paging request at virtual address
ffc070a0
<1>[ 154.846576] Mem abort info:
<1>[ 154.846635] Exception class = DABT (current EL), IL = 32 bits
<1>[ 154.846737] SET = 0, FnV = 0
<1>[ 154.846796] EA = 0, S1PTW = 0
<1>[ 154.846859] Data abort info:
<1>[ 154.846913] ISV = 0, ISS = 0x0006
<1>[ 154.846983] CM = 0, WnR = 0
<1>[ 154.847053] swapper pgtable: 4k pages, 39-bit VAs, pgd = ff8009df7000
<1>[ 154.847228] [ffc070a0] *pgd=00087fff5803,
*pud=00087fff5803, *pmd=
<0>[ 154.847408] Internal error: Oops: 9606 [#1] PREEMPT SMP
<4>[ 154.847511] Modules linked in: nvs_led_test nvs_bmi160 nvs_cm3218
nvs_bh1730fvc nvi_bmpX80 nvi_ak89xx nvi_mpu cdc_acm uas lr388k7_ts imx268
imx318 imx204 imx274 imx185 lc898212 ov23850 ov10823 ov9281 ov5693 tc358840
pca9570 nvs snd_soc_tegra_machine_driver_mobile lp855x_bl spidev input_cfboost
pwm_tegra tegra_cryptodev tegra_se_nvhost tegra_se_elp tegra_se ghash_ce
sha2_ce sha1_ce aes_ce_ccm cryptd nvgpu cpufreq_userspace
snd_soc_tegra186_alt_dspk snd_soc_tegra186_alt_asrc snd_soc_tegra186_alt_arad
snd_soc_tegra210_alt_ope snd_soc_tegra210_alt_mvc snd_soc_tegra210_alt_dmic
snd_soc_tegra210_alt_amx snd_soc_tegra210_alt_adx snd_soc_tegra210_alt_afc
snd_soc_tegra210_alt_mixer snd_soc_tegra210_alt_i2s snd_soc_tegra210_alt_sfc
snd_soc_tegra210_alt_adsp snd_soc_tegra210_alt_admaif snd_soc_tegra210_alt_xbar
<4>[ 154.882606] snd_soc_tegra_alt_utils snd_hda_tegra
<4>[ 154.888133] CPU: 2 PID: 8079 Comm: sh Not tainted
4.14.53-tegra-05132-g9c33465 #2
<4>[ 154.895983] Hardware name: e3360_1099 (DT)
<4>[ 154.900447] task: ffc7d62dda00 task.stack: ff800e2b
<4>[ 154.906502] PC is at scan_block+0x7c/0x148
<4>[ 154.911234] LR is at scan_block+0x78/0x148
<4>[ 154.915689] pc : [] lr : [] pstate:
804000c9
<4>[ 154.923290] sp : ff800e2b3b80
<4>[ 154.927228] x29: ff800e2b3b80 x28: ffc7d62dda00
<4>[ 154.932999] x27: ff8009aaa000 x26: ffc070c0
<4>[ 154.938769] x25: 00c0 x24: ff8009d90608
<4>[ 154.944287] x23: ffc7dc6c6000 x22: ff8009d9
<4>[ 154.950320] x21: ff8009aeb320 x20: ffc070a00ff9
<4>[ 154.955919] x19: ffc070a0 x18: bec4c3f2
<4>[ 154.961438] x17: 002224777924 x16: ff80080bb0e0
<4>[ 154.967124] x15: x14: 0f75
<4>[ 154.973069] x13: 000f x12: ffbf1e9f4240
<4>[ 154.978670] x11: 0040 x10: 0ad0
<4>[ 154.984107] x9 : ff800e2b3ab0 x8 : ffc7d62de530
<4>[ 154.989958] x7 : 00078000 x6 : 0018
<4>[ 154.995645] x5 : x4 :
<4>[ 155.001245] x3 : ff8009aaa000 x2 : 0047f6712000
<4>[ 155.006846] x1 : ffc7d1ae6900 x0 :
Signed-off-by: Sri Krishna chowdary
Signed-off-by: Prateek
---
drivers/of/of_reserved_mem.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 1977ee0..ac8f377 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#define MAX_RESERVED_REGIONS 32
static struct reserved_mem reserved_mem[MAX_RESERVED_REGIONS];
@@ -50,8 +51,10 @@ int __init __weak
early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
}
*res_base = base;
- if (nomap)
+ if (nomap) {
+ kmemleak_no_scan(__va(base));
return memblock_remove(base, size);
+ }
return 0;
}
--
2.1.4
[PATCH] of: reserved_mem: disable kmemleak scan on removed memory blocks
From: Sri Krishna chowdary
Memory reserved with "nomap" DT property in of_reserved_mem.c
removes the memory block. The removed memory blocks don't have
VA to PA mapping created in kernel page table. Kmemleak scan on
removed memory blocks is causing page faults and leading to
kernel panic. So, Disable kmemleak scan on the removed memory
blocks.
Following is the observed crash log:
[ 154.846370] Unable to handle kernel paging request at virtual address
ffc070a0
<1>[ 154.846576] Mem abort info:
<1>[ 154.846635] Exception class = DABT (current EL), IL = 32 bits
<1>[ 154.846737] SET = 0, FnV = 0
<1>[ 154.846796] EA = 0, S1PTW = 0
<1>[ 154.846859] Data abort info:
<1>[ 154.846913] ISV = 0, ISS = 0x0006
<1>[ 154.846983] CM = 0, WnR = 0
<1>[ 154.847053] swapper pgtable: 4k pages, 39-bit VAs, pgd = ff8009df7000
<1>[ 154.847228] [ffc070a0] *pgd=00087fff5803,
*pud=00087fff5803, *pmd=
<0>[ 154.847408] Internal error: Oops: 9606 [#1] PREEMPT SMP
<4>[ 154.847511] Modules linked in: nvs_led_test nvs_bmi160 nvs_cm3218
nvs_bh1730fvc nvi_bmpX80 nvi_ak89xx nvi_mpu cdc_acm uas lr388k7_ts imx268
imx318 imx204 imx274 imx185 lc898212 ov23850 ov10823 ov9281 ov5693 tc358840
pca9570 nvs snd_soc_tegra_machine_driver_mobile lp855x_bl spidev input_cfboost
pwm_tegra tegra_cryptodev tegra_se_nvhost tegra_se_elp tegra_se ghash_ce
sha2_ce sha1_ce aes_ce_ccm cryptd nvgpu cpufreq_userspace
snd_soc_tegra186_alt_dspk snd_soc_tegra186_alt_asrc snd_soc_tegra186_alt_arad
snd_soc_tegra210_alt_ope snd_soc_tegra210_alt_mvc snd_soc_tegra210_alt_dmic
snd_soc_tegra210_alt_amx snd_soc_tegra210_alt_adx snd_soc_tegra210_alt_afc
snd_soc_tegra210_alt_mixer snd_soc_tegra210_alt_i2s snd_soc_tegra210_alt_sfc
snd_soc_tegra210_alt_adsp snd_soc_tegra210_alt_admaif snd_soc_tegra210_alt_xbar
<4>[ 154.882606] snd_soc_tegra_alt_utils snd_hda_tegra
<4>[ 154.888133] CPU: 2 PID: 8079 Comm: sh Not tainted
4.14.53-tegra-05132-g9c33465 #2
<4>[ 154.895983] Hardware name: e3360_1099 (DT)
<4>[ 154.900447] task: ffc7d62dda00 task.stack: ff800e2b
<4>[ 154.906502] PC is at scan_block+0x7c/0x148
<4>[ 154.911234] LR is at scan_block+0x78/0x148
<4>[ 154.915689] pc : [] lr : [] pstate:
804000c9
<4>[ 154.923290] sp : ff800e2b3b80
<4>[ 154.927228] x29: ff800e2b3b80 x28: ffc7d62dda00
<4>[ 154.932999] x27: ff8009aaa000 x26: ffc070c0
<4>[ 154.938769] x25: 00c0 x24: ff8009d90608
<4>[ 154.944287] x23: ffc7dc6c6000 x22: ff8009d9
<4>[ 154.950320] x21: ff8009aeb320 x20: ffc070a00ff9
<4>[ 154.955919] x19: ffc070a0 x18: bec4c3f2
<4>[ 154.961438] x17: 002224777924 x16: ff80080bb0e0
<4>[ 154.967124] x15: x14: 0f75
<4>[ 154.973069] x13: 000f x12: ffbf1e9f4240
<4>[ 154.978670] x11: 0040 x10: 0ad0
<4>[ 154.984107] x9 : ff800e2b3ab0 x8 : ffc7d62de530
<4>[ 154.989958] x7 : 00078000 x6 : 0018
<4>[ 154.995645] x5 : x4 :
<4>[ 155.001245] x3 : ff8009aaa000 x2 : 0047f6712000
<4>[ 155.006846] x1 : ffc7d1ae6900 x0 :
Signed-off-by: Sri Krishna chowdary
Signed-off-by: Prateek
---
drivers/of/of_reserved_mem.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c
index 1977ee0..ac8f377 100644
--- a/drivers/of/of_reserved_mem.c
+++ b/drivers/of/of_reserved_mem.c
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#define MAX_RESERVED_REGIONS 32
static struct reserved_mem reserved_mem[MAX_RESERVED_REGIONS];
@@ -50,8 +51,10 @@ int __init __weak
early_init_dt_alloc_reserved_memory_arch(phys_addr_t size,
}
*res_base = base;
- if (nomap)
+ if (nomap) {
+ kmemleak_no_scan(__va(base));
return memblock_remove(base, size);
+ }
return 0;
}
--
2.1.4
[PATCH V2] kmemleak: Add config to select auto scan
From: Sri Krishna chowdary
Kmemleak scan can be cpu intensive and can stall user tasks at times.
To prevent this, add config DEBUG_KMEMLEAK_AUTO_SCAN to enable/disable
auto scan on boot up.
Also protect first_run with DEBUG_KMEMLEAK_AUTO_SCAN as this is meant
for only first automatic scan.
Signed-off-by: Sri Krishna chowdary
Signed-off-by: Sachin Nikam
Signed-off-by: Prateek
---
v2:
* change config name to DEBUG_KMEMLEAK_AUTO_SCAN from DEBUG_KMEMLEAK_SCAN_ON
* use IS_ENABLED(...) instead of #ifdef ...
* update commit message according to config name
---
lib/Kconfig.debug | 15 +++
mm/kmemleak.c | 10 ++
2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index c958013..a14166d 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -593,6 +593,21 @@ config DEBUG_KMEMLEAK_DEFAULT_OFF
Say Y here to disable kmemleak by default. It can then be enabled
on the command line via kmemleak=on.
+config DEBUG_KMEMLEAK_AUTO_SCAN
+ bool "Enable kmemleak auto scan thread on boot up"
+ default y
+ depends on DEBUG_KMEMLEAK
+ help
+ Depending on the cpu, kmemleak scan may be cpu intensive and can
+ stall user tasks at times. This option enables/disables automatic
+ kmemleak scan at boot up.
+
+ Say N here to disable kmemleak auto scan thread to stop automatic
+ scanning. Disabling this option disables automatic reporting of
+ memory leaks.
+
+ If unsure, say Y.
+
config DEBUG_STACK_USAGE
bool "Stack utilization instrumentation"
depends on DEBUG_KERNEL && !IA64
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index 877de4f..a614930 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -1647,7 +1647,7 @@ static void kmemleak_scan(void)
*/
static int kmemleak_scan_thread(void *arg)
{
- static int first_run = 1;
+ static int first_run = IS_ENABLED(CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN);
pr_info("Automatic memory scanning thread started\n");
set_user_nice(current, 10);
@@ -2141,9 +2141,11 @@ static int __init kmemleak_late_init(void)
return -ENOMEM;
}
- mutex_lock(_mutex);
- start_scan_thread();
- mutex_unlock(_mutex);
+ if (IS_ENABLED(CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN)) {
+ mutex_lock(_mutex);
+ start_scan_thread();
+ mutex_unlock(_mutex);
+ }
pr_info("Kernel memory leak detector initialized\n");
--
2.1.4
[PATCH V2] kmemleak: Add config to select auto scan
From: Sri Krishna chowdary
Kmemleak scan can be cpu intensive and can stall user tasks at times.
To prevent this, add config DEBUG_KMEMLEAK_AUTO_SCAN to enable/disable
auto scan on boot up.
Also protect first_run with DEBUG_KMEMLEAK_AUTO_SCAN as this is meant
for only first automatic scan.
Signed-off-by: Sri Krishna chowdary
Signed-off-by: Sachin Nikam
Signed-off-by: Prateek
---
v2:
* change config name to DEBUG_KMEMLEAK_AUTO_SCAN from DEBUG_KMEMLEAK_SCAN_ON
* use IS_ENABLED(...) instead of #ifdef ...
* update commit message according to config name
---
lib/Kconfig.debug | 15 +++
mm/kmemleak.c | 10 ++
2 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index c958013..a14166d 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -593,6 +593,21 @@ config DEBUG_KMEMLEAK_DEFAULT_OFF
Say Y here to disable kmemleak by default. It can then be enabled
on the command line via kmemleak=on.
+config DEBUG_KMEMLEAK_AUTO_SCAN
+ bool "Enable kmemleak auto scan thread on boot up"
+ default y
+ depends on DEBUG_KMEMLEAK
+ help
+ Depending on the cpu, kmemleak scan may be cpu intensive and can
+ stall user tasks at times. This option enables/disables automatic
+ kmemleak scan at boot up.
+
+ Say N here to disable kmemleak auto scan thread to stop automatic
+ scanning. Disabling this option disables automatic reporting of
+ memory leaks.
+
+ If unsure, say Y.
+
config DEBUG_STACK_USAGE
bool "Stack utilization instrumentation"
depends on DEBUG_KERNEL && !IA64
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index 877de4f..a614930 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -1647,7 +1647,7 @@ static void kmemleak_scan(void)
*/
static int kmemleak_scan_thread(void *arg)
{
- static int first_run = 1;
+ static int first_run = IS_ENABLED(CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN);
pr_info("Automatic memory scanning thread started\n");
set_user_nice(current, 10);
@@ -2141,9 +2141,11 @@ static int __init kmemleak_late_init(void)
return -ENOMEM;
}
- mutex_lock(_mutex);
- start_scan_thread();
- mutex_unlock(_mutex);
+ if (IS_ENABLED(CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN)) {
+ mutex_lock(_mutex);
+ start_scan_thread();
+ mutex_unlock(_mutex);
+ }
pr_info("Kernel memory leak detector initialized\n");
--
2.1.4
[PATCH] kmemleak: Add config to select auto scan
From: Sri Krishna chowdary
Kmemleak scan is cpu intensive and can stall user tasks at times.
To prevent this, add config DEBUG_KMEMLEAK_SCAN_ON to enable/disable
auto scan on boot up.
Also protect first_run with CONFIG_DEBUG_KMEMLEAK_SCAN_ON as this is
meant for only first automatic scan.
Signed-off-by: Sri Krishna chowdary
Signed-off-by: Sachin Nikam
Signed-off-by: Prateek
---
lib/Kconfig.debug | 11 +++
mm/kmemleak.c | 6 ++
2 files changed, 17 insertions(+)
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index e5e7c03..9542852 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -593,6 +593,17 @@ config DEBUG_KMEMLEAK_DEFAULT_OFF
Say Y here to disable kmemleak by default. It can then be enabled
on the command line via kmemleak=on.
+config DEBUG_KMEMLEAK_SCAN_ON
+ bool "Enable kmemleak auto scan thread on boot up"
+ default y
+ depends on DEBUG_KMEMLEAK
+ help
+ Kmemleak scan is cpu intensive and can stall user tasks at times.
+ This option enables/disables automatic kmemleak scan at boot up.
+
+ Say N here to disable kmemleak auto scan thread to stop automatic
+ scanning.
+
config DEBUG_STACK_USAGE
bool "Stack utilization instrumentation"
depends on DEBUG_KERNEL && !IA64
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index 877de4f..ac53678 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -1647,11 +1647,14 @@ static void kmemleak_scan(void)
*/
static int kmemleak_scan_thread(void *arg)
{
+#ifdef CONFIG_DEBUG_KMEMLEAK_SCAN_ON
static int first_run = 1;
+#endif
pr_info("Automatic memory scanning thread started\n");
set_user_nice(current, 10);
+#ifdef CONFIG_DEBUG_KMEMLEAK_SCAN_ON
/*
* Wait before the first scan to allow the system to fully initialize.
*/
@@ -1661,6 +1664,7 @@ static int kmemleak_scan_thread(void *arg)
while (timeout && !kthread_should_stop())
timeout = schedule_timeout_interruptible(timeout);
}
+#endif
while (!kthread_should_stop()) {
signed long timeout = jiffies_scan_wait;
@@ -2141,9 +2145,11 @@ static int __init kmemleak_late_init(void)
return -ENOMEM;
}
+#ifdef CONFIG_DEBUG_KMEMLEAK_SCAN_ON
mutex_lock(_mutex);
start_scan_thread();
mutex_unlock(_mutex);
+#endif
pr_info("Kernel memory leak detector initialized\n");
--
2.1.4
[PATCH] kmemleak: Add config to select auto scan
From: Sri Krishna chowdary
Kmemleak scan is cpu intensive and can stall user tasks at times.
To prevent this, add config DEBUG_KMEMLEAK_SCAN_ON to enable/disable
auto scan on boot up.
Also protect first_run with CONFIG_DEBUG_KMEMLEAK_SCAN_ON as this is
meant for only first automatic scan.
Signed-off-by: Sri Krishna chowdary
Signed-off-by: Sachin Nikam
Signed-off-by: Prateek
---
lib/Kconfig.debug | 11 +++
mm/kmemleak.c | 6 ++
2 files changed, 17 insertions(+)
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index e5e7c03..9542852 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -593,6 +593,17 @@ config DEBUG_KMEMLEAK_DEFAULT_OFF
Say Y here to disable kmemleak by default. It can then be enabled
on the command line via kmemleak=on.
+config DEBUG_KMEMLEAK_SCAN_ON
+ bool "Enable kmemleak auto scan thread on boot up"
+ default y
+ depends on DEBUG_KMEMLEAK
+ help
+ Kmemleak scan is cpu intensive and can stall user tasks at times.
+ This option enables/disables automatic kmemleak scan at boot up.
+
+ Say N here to disable kmemleak auto scan thread to stop automatic
+ scanning.
+
config DEBUG_STACK_USAGE
bool "Stack utilization instrumentation"
depends on DEBUG_KERNEL && !IA64
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index 877de4f..ac53678 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -1647,11 +1647,14 @@ static void kmemleak_scan(void)
*/
static int kmemleak_scan_thread(void *arg)
{
+#ifdef CONFIG_DEBUG_KMEMLEAK_SCAN_ON
static int first_run = 1;
+#endif
pr_info("Automatic memory scanning thread started\n");
set_user_nice(current, 10);
+#ifdef CONFIG_DEBUG_KMEMLEAK_SCAN_ON
/*
* Wait before the first scan to allow the system to fully initialize.
*/
@@ -1661,6 +1664,7 @@ static int kmemleak_scan_thread(void *arg)
while (timeout && !kthread_should_stop())
timeout = schedule_timeout_interruptible(timeout);
}
+#endif
while (!kthread_should_stop()) {
signed long timeout = jiffies_scan_wait;
@@ -2141,9 +2145,11 @@ static int __init kmemleak_late_init(void)
return -ENOMEM;
}
+#ifdef CONFIG_DEBUG_KMEMLEAK_SCAN_ON
mutex_lock(_mutex);
start_scan_thread();
mutex_unlock(_mutex);
+#endif
pr_info("Kernel memory leak detector initialized\n");
--
2.1.4
