kmemleak: 2 new suspected memory leaks #38
Comments
bcopeland
added a commit
that referenced
this issue
Oct 2, 2013
If the firmware loader callback is queued before suspend but invoked on resume, we will try to set up the card even though some things like the mmc controller may not be there anymore. This can cause a crash or warnings like the one below. Wait for the callback before leaving remove(). Fixes: [ 112.506713] ------------[ cut here ]------------ [ 112.514282] WARNING: at lib/kobject.c:196 kobject_add_internal+0x1c4/0x230() [ 112.523956] kobject_add_internal failed for phy1 with -EEXIST, don't try to register things with the same name in the same directory. [ 112.536621] Modules linked in: arc4 mwl8787_sdio mac80211 cfg80211 [ 112.541351] CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: G W 3.10.0 #38 [ 112.550781] Workqueue: events request_firmware_work_func [ 112.551239] [<c001b4b4>] (unwind_backtrace+0x0/0x130) from [<c0017b7c>] (show_stack+0x10/0x14) [ 112.565490] [<c0017b7c>] (show_stack+0x10/0x14) from [<c0043890>] (warn_slowpath_common+0x4c/0x68) [ 112.575012] [<c0043890>] (warn_slowpath_common+0x4c/0x68) from [<c0043940>] (warn_slowpath_fmt+0x30/0x40) [ 112.585144] [<c0043940>] (warn_slowpath_fmt+0x30/0x40) from [<c02b7ad4>] (kobject_add_internal+0x1c4/0x230) [ 112.595458] [<c02b7ad4>] (kobject_add_internal+0x1c4/0x230) from [<c02b7d6c>] (kobject_add+0x50/0x98) [ 112.605194] [<c02b7d6c>] (kobject_add+0x50/0x98) from [<c03254f8>] (device_add+0xcc/0x5c4) [ 112.614105] [<c03254f8>] (device_add+0xcc/0x5c4) from [<bf000920>] (wiphy_register+0x408/0x67c [cfg80211]) [ 112.624572] [<bf000920>] (wiphy_register+0x408/0x67c [cfg80211]) from [<bf08e55c>] (ieee80211_register_hw+0x3c4/0x810 [mac80211]) [ 112.637084] [<bf08e55c>] (ieee80211_register_hw+0x3c4/0x810 [mac80211]) from [<bf144df0>] (mwl8787_register+0x10/0x38 [mwl8787_sdio]) [ 112.649810] [<bf144df0>] (mwl8787_register+0x10/0x38 [mwl8787_sdio]) from [<bf146fd8>] (mwl8787_fw_cb+0x64/0x84 [mwl8787_sdio]) [ 112.661926] [<bf146fd8>] (mwl8787_fw_cb+0x64/0x84 [mwl8787_sdio]) from [<c0335da8>] (request_firmware_work_func+0x40/0x64) [ 112.673645] [<c0335da8>] (request_firmware_work_func+0x40/0x64) from [<c005f4b0>] (process_one_work+0x1ac/0x4c8) [ 112.684417] [<c005f4b0>] (process_one_work+0x1ac/0x4c8) from [<c005fc0c>] (worker_thread+0x144/0x3ac) [ 112.694152] [<c005fc0c>] (worker_thread+0x144/0x3ac) from [<c0065b6c>] (kthread+0xa4/0xb0) [ 112.702880] [<c0065b6c>] (kthread+0xa4/0xb0) from [<c0013c28>] (ret_from_fork+0x14/0x2c) [ 112.704925] ---[ end trace 92baea39fd3e9318 ]--- Signed-off-by: Bob Copeland <me@bobcopeland.com>
bcopeland
added a commit
that referenced
this issue
Nov 6, 2013
If the firmware loader callback is queued before suspend but invoked on resume, we will try to set up the card even though some things like the mmc controller may not be there anymore. This can cause a crash or warnings like the one below. Wait for the callback before leaving remove(). Fixes: [ 112.506713] ------------[ cut here ]------------ [ 112.514282] WARNING: at lib/kobject.c:196 kobject_add_internal+0x1c4/0x230() [ 112.523956] kobject_add_internal failed for phy1 with -EEXIST, don't try to register things with the same name in the same directory. [ 112.536621] Modules linked in: arc4 mwl8787_sdio mac80211 cfg80211 [ 112.541351] CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: G W 3.10.0 #38 [ 112.550781] Workqueue: events request_firmware_work_func [ 112.551239] [<c001b4b4>] (unwind_backtrace+0x0/0x130) from [<c0017b7c>] (show_stack+0x10/0x14) [ 112.565490] [<c0017b7c>] (show_stack+0x10/0x14) from [<c0043890>] (warn_slowpath_common+0x4c/0x68) [ 112.575012] [<c0043890>] (warn_slowpath_common+0x4c/0x68) from [<c0043940>] (warn_slowpath_fmt+0x30/0x40) [ 112.585144] [<c0043940>] (warn_slowpath_fmt+0x30/0x40) from [<c02b7ad4>] (kobject_add_internal+0x1c4/0x230) [ 112.595458] [<c02b7ad4>] (kobject_add_internal+0x1c4/0x230) from [<c02b7d6c>] (kobject_add+0x50/0x98) [ 112.605194] [<c02b7d6c>] (kobject_add+0x50/0x98) from [<c03254f8>] (device_add+0xcc/0x5c4) [ 112.614105] [<c03254f8>] (device_add+0xcc/0x5c4) from [<bf000920>] (wiphy_register+0x408/0x67c [cfg80211]) [ 112.624572] [<bf000920>] (wiphy_register+0x408/0x67c [cfg80211]) from [<bf08e55c>] (ieee80211_register_hw+0x3c4/0x810 [mac80211]) [ 112.637084] [<bf08e55c>] (ieee80211_register_hw+0x3c4/0x810 [mac80211]) from [<bf144df0>] (mwl8787_register+0x10/0x38 [mwl8787_sdio]) [ 112.649810] [<bf144df0>] (mwl8787_register+0x10/0x38 [mwl8787_sdio]) from [<bf146fd8>] (mwl8787_fw_cb+0x64/0x84 [mwl8787_sdio]) [ 112.661926] [<bf146fd8>] (mwl8787_fw_cb+0x64/0x84 [mwl8787_sdio]) from [<c0335da8>] (request_firmware_work_func+0x40/0x64) [ 112.673645] [<c0335da8>] (request_firmware_work_func+0x40/0x64) from [<c005f4b0>] (process_one_work+0x1ac/0x4c8) [ 112.684417] [<c005f4b0>] (process_one_work+0x1ac/0x4c8) from [<c005fc0c>] (worker_thread+0x144/0x3ac) [ 112.694152] [<c005fc0c>] (worker_thread+0x144/0x3ac) from [<c0065b6c>] (kthread+0xa4/0xb0) [ 112.702880] [<c0065b6c>] (kthread+0xa4/0xb0) from [<c0013c28>] (ret_from_fork+0x14/0x2c) [ 112.704925] ---[ end trace 92baea39fd3e9318 ]--- Signed-off-by: Bob Copeland <me@bobcopeland.com>
silverjam
pushed a commit
that referenced
this issue
Nov 19, 2013
As the new x86 CPU bootup printout format code maintainer, I am taking immediate action to improve and clean (and thus indulge my OCD) the reporting of the cores when coming up online. Fix padding to a right-hand alignment, cleanup code and bind reporting width to the max number of supported CPUs on the system, like this: [ 0.074509] smpboot: Booting Node 0, Processors: #1 #2 #3 #4 #5 #6 #7 OK [ 0.644008] smpboot: Booting Node 1, Processors: #8 #9 #10 #11 #12 #13 #14 #15 OK [ 1.245006] smpboot: Booting Node 2, Processors: #16 #17 #18 #19 #20 #21 #22 #23 OK [ 1.864005] smpboot: Booting Node 3, Processors: #24 #25 #26 #27 #28 #29 #30 #31 OK [ 2.489005] smpboot: Booting Node 4, Processors: #32 #33 #34 #35 #36 #37 #38 #39 OK [ 3.093005] smpboot: Booting Node 5, Processors: #40 #41 #42 #43 #44 #45 #46 #47 OK [ 3.698005] smpboot: Booting Node 6, Processors: #48 #49 #50 #51 #52 #53 #54 #55 OK [ 4.304005] smpboot: Booting Node 7, Processors: #56 #57 #58 #59 #60 #61 #62 #63 OK [ 4.961413] Brought up 64 CPUs and this: [ 0.072367] smpboot: Booting Node 0, Processors: #1 #2 #3 #4 #5 #6 #7 OK [ 0.686329] Brought up 8 CPUs Signed-off-by: Borislav Petkov <bp@suse.de> Cc: Libin <huawei.libin@huawei.com> Cc: wangyijing@huawei.com Cc: fenghua.yu@intel.com Cc: guohanjun@huawei.com Cc: paul.gortmaker@windriver.com Link: http://lkml.kernel.org/r/20130927143554.GF4422@pd.tnic Signed-off-by: Ingo Molnar <mingo@kernel.org>
silverjam
pushed a commit
that referenced
this issue
Nov 19, 2013
Turn it into (for example): [ 0.073380] x86: Booting SMP configuration: [ 0.074005] .... node #0, CPUs: #1 #2 #3 #4 #5 #6 #7 [ 0.603005] .... node #1, CPUs: #8 #9 #10 #11 #12 #13 #14 #15 [ 1.200005] .... node #2, CPUs: #16 #17 #18 #19 #20 #21 #22 #23 [ 1.796005] .... node #3, CPUs: #24 #25 #26 #27 #28 #29 #30 #31 [ 2.393005] .... node #4, CPUs: #32 #33 #34 #35 #36 #37 #38 #39 [ 2.996005] .... node #5, CPUs: #40 #41 #42 #43 #44 #45 #46 #47 [ 3.600005] .... node #6, CPUs: #48 #49 #50 #51 #52 #53 #54 #55 [ 4.202005] .... node #7, CPUs: #56 #57 #58 #59 #60 #61 #62 #63 [ 4.811005] .... node #8, CPUs: #64 #65 #66 #67 #68 #69 #70 #71 [ 5.421006] .... node #9, CPUs: #72 #73 #74 #75 #76 #77 #78 #79 [ 6.032005] .... node #10, CPUs: #80 #81 #82 #83 #84 #85 #86 #87 [ 6.648006] .... node #11, CPUs: #88 #89 #90 #91 #92 #93 #94 #95 [ 7.262005] .... node #12, CPUs: #96 #97 #98 #99 #100 #101 #102 #103 [ 7.865005] .... node #13, CPUs: #104 #105 #106 #107 #108 #109 #110 #111 [ 8.466005] .... node #14, CPUs: #112 #113 #114 #115 #116 #117 #118 #119 [ 9.073006] .... node #15, CPUs: #120 #121 #122 #123 #124 #125 #126 #127 [ 9.679901] x86: Booted up 16 nodes, 128 CPUs and drop useless elements. Change num_digits() to hpa's division-avoiding, cell-phone-typed version which he went at great lengths and pains to submit on a Saturday evening. Signed-off-by: Borislav Petkov <bp@suse.de> Cc: huawei.libin@huawei.com Cc: wangyijing@huawei.com Cc: fenghua.yu@intel.com Cc: guohanjun@huawei.com Cc: paul.gortmaker@windriver.com Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/20130930095624.GB16383@pd.tnic Signed-off-by: Ingo Molnar <mingo@kernel.org>
silverjam
pushed a commit
that referenced
this issue
Nov 19, 2013
…hing Dave Jones reported that trinity would be able to trigger the following back trace: =============================== [ INFO: suspicious RCU usage. ] 3.10.0-rc2+ #38 Not tainted ------------------------------- include/linux/rcupdate.h:771 rcu_read_lock() used illegally while idle! other info that might help us debug this: RCU used illegally from idle CPU! rcu_scheduler_active = 1, debug_locks = 0 RCU used illegally from extended quiescent state! 1 lock held by trinity-child1/18786: #0: (rcu_read_lock){.+.+..}, at: [<ffffffff8113dd48>] __perf_event_overflow+0x108/0x310 stack backtrace: CPU: 3 PID: 18786 Comm: trinity-child1 Not tainted 3.10.0-rc2+ #38 0000000000000000 ffff88020767bac8 ffffffff816e2f6b ffff88020767baf8 ffffffff810b5897 ffff88021de92520 0000000000000000 ffff88020767bbf8 0000000000000000 ffff88020767bb78 ffffffff8113ded4 ffffffff8113dd48 Call Trace: [<ffffffff816e2f6b>] dump_stack+0x19/0x1b [<ffffffff810b5897>] lockdep_rcu_suspicious+0xe7/0x120 [<ffffffff8113ded4>] __perf_event_overflow+0x294/0x310 [<ffffffff8113dd48>] ? __perf_event_overflow+0x108/0x310 [<ffffffff81309289>] ? __const_udelay+0x29/0x30 [<ffffffff81076054>] ? __rcu_read_unlock+0x54/0xa0 [<ffffffff816f4000>] ? ftrace_call+0x5/0x2f [<ffffffff8113dfa1>] perf_swevent_overflow+0x51/0xe0 [<ffffffff8113e08f>] perf_swevent_event+0x5f/0x90 [<ffffffff8113e1c9>] perf_tp_event+0x109/0x4f0 [<ffffffff8113e36f>] ? perf_tp_event+0x2af/0x4f0 [<ffffffff81074630>] ? __rcu_read_lock+0x20/0x20 [<ffffffff8112d79f>] perf_ftrace_function_call+0xbf/0xd0 [<ffffffff8110e1e1>] ? ftrace_ops_control_func+0x181/0x210 [<ffffffff81074630>] ? __rcu_read_lock+0x20/0x20 [<ffffffff81100cae>] ? rcu_eqs_enter_common+0x5e/0x470 [<ffffffff8110e1e1>] ftrace_ops_control_func+0x181/0x210 [<ffffffff816f4000>] ftrace_call+0x5/0x2f [<ffffffff8110e229>] ? ftrace_ops_control_func+0x1c9/0x210 [<ffffffff816f4000>] ? ftrace_call+0x5/0x2f [<ffffffff81074635>] ? debug_lockdep_rcu_enabled+0x5/0x40 [<ffffffff81074635>] ? debug_lockdep_rcu_enabled+0x5/0x40 [<ffffffff81100cae>] ? rcu_eqs_enter_common+0x5e/0x470 [<ffffffff8110112a>] rcu_eqs_enter+0x6a/0xb0 [<ffffffff81103673>] rcu_user_enter+0x13/0x20 [<ffffffff8114541a>] user_enter+0x6a/0xd0 [<ffffffff8100f6d8>] syscall_trace_leave+0x78/0x140 [<ffffffff816f46af>] int_check_syscall_exit_work+0x34/0x3d ------------[ cut here ]------------ Perf uses rcu_read_lock() but as the function tracer can trace functions even when RCU is not currently active, this makes the rcu_read_lock() used by perf ineffective. As perf is currently the only user of the ftrace_ops_control_func() and perf is also the only function callback that actively uses rcu_read_lock(), the quick fix is to prevent the ftrace_ops_control_func() from calling its callbacks if RCU is not active. With Paul's new "rcu_is_watching()" we can tell if RCU is active or not. Reported-by: Dave Jones <davej@redhat.com> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Jiri Olsa <jolsa@redhat.com> Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
bcopeland
added a commit
that referenced
this issue
Nov 22, 2013
If the firmware loader callback is queued before suspend but invoked on resume, we will try to set up the card even though some things like the mmc controller may not be there anymore. This can cause a crash or warnings like the one below. Wait for the callback before leaving remove(). Fixes: [ 112.506713] ------------[ cut here ]------------ [ 112.514282] WARNING: at lib/kobject.c:196 kobject_add_internal+0x1c4/0x230() [ 112.523956] kobject_add_internal failed for phy1 with -EEXIST, don't try to register things with the same name in the same directory. [ 112.536621] Modules linked in: arc4 mwl8787_sdio mac80211 cfg80211 [ 112.541351] CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: G W 3.10.0 #38 [ 112.550781] Workqueue: events request_firmware_work_func [ 112.551239] [<c001b4b4>] (unwind_backtrace+0x0/0x130) from [<c0017b7c>] (show_stack+0x10/0x14) [ 112.565490] [<c0017b7c>] (show_stack+0x10/0x14) from [<c0043890>] (warn_slowpath_common+0x4c/0x68) [ 112.575012] [<c0043890>] (warn_slowpath_common+0x4c/0x68) from [<c0043940>] (warn_slowpath_fmt+0x30/0x40) [ 112.585144] [<c0043940>] (warn_slowpath_fmt+0x30/0x40) from [<c02b7ad4>] (kobject_add_internal+0x1c4/0x230) [ 112.595458] [<c02b7ad4>] (kobject_add_internal+0x1c4/0x230) from [<c02b7d6c>] (kobject_add+0x50/0x98) [ 112.605194] [<c02b7d6c>] (kobject_add+0x50/0x98) from [<c03254f8>] (device_add+0xcc/0x5c4) [ 112.614105] [<c03254f8>] (device_add+0xcc/0x5c4) from [<bf000920>] (wiphy_register+0x408/0x67c [cfg80211]) [ 112.624572] [<bf000920>] (wiphy_register+0x408/0x67c [cfg80211]) from [<bf08e55c>] (ieee80211_register_hw+0x3c4/0x810 [mac80211]) [ 112.637084] [<bf08e55c>] (ieee80211_register_hw+0x3c4/0x810 [mac80211]) from [<bf144df0>] (mwl8787_register+0x10/0x38 [mwl8787_sdio]) [ 112.649810] [<bf144df0>] (mwl8787_register+0x10/0x38 [mwl8787_sdio]) from [<bf146fd8>] (mwl8787_fw_cb+0x64/0x84 [mwl8787_sdio]) [ 112.661926] [<bf146fd8>] (mwl8787_fw_cb+0x64/0x84 [mwl8787_sdio]) from [<c0335da8>] (request_firmware_work_func+0x40/0x64) [ 112.673645] [<c0335da8>] (request_firmware_work_func+0x40/0x64) from [<c005f4b0>] (process_one_work+0x1ac/0x4c8) [ 112.684417] [<c005f4b0>] (process_one_work+0x1ac/0x4c8) from [<c005fc0c>] (worker_thread+0x144/0x3ac) [ 112.694152] [<c005fc0c>] (worker_thread+0x144/0x3ac) from [<c0065b6c>] (kthread+0xa4/0xb0) [ 112.702880] [<c0065b6c>] (kthread+0xa4/0xb0) from [<c0013c28>] (ret_from_fork+0x14/0x2c) [ 112.704925] ---[ end trace 92baea39fd3e9318 ]--- Signed-off-by: Bob Copeland <me@bobcopeland.com>
bcopeland
added a commit
that referenced
this issue
Nov 22, 2013
If the firmware loader callback is queued before suspend but invoked on resume, we will try to set up the card even though some things like the mmc controller may not be there anymore. This can cause a crash or warnings like the one below. Wait for the callback before leaving remove(). Fixes: [ 112.506713] ------------[ cut here ]------------ [ 112.514282] WARNING: at lib/kobject.c:196 kobject_add_internal+0x1c4/0x230() [ 112.523956] kobject_add_internal failed for phy1 with -EEXIST, don't try to register things with the same name in the same directory. [ 112.536621] Modules linked in: arc4 mwl8787_sdio mac80211 cfg80211 [ 112.541351] CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: G W 3.10.0 #38 [ 112.550781] Workqueue: events request_firmware_work_func [ 112.551239] [<c001b4b4>] (unwind_backtrace+0x0/0x130) from [<c0017b7c>] (show_stack+0x10/0x14) [ 112.565490] [<c0017b7c>] (show_stack+0x10/0x14) from [<c0043890>] (warn_slowpath_common+0x4c/0x68) [ 112.575012] [<c0043890>] (warn_slowpath_common+0x4c/0x68) from [<c0043940>] (warn_slowpath_fmt+0x30/0x40) [ 112.585144] [<c0043940>] (warn_slowpath_fmt+0x30/0x40) from [<c02b7ad4>] (kobject_add_internal+0x1c4/0x230) [ 112.595458] [<c02b7ad4>] (kobject_add_internal+0x1c4/0x230) from [<c02b7d6c>] (kobject_add+0x50/0x98) [ 112.605194] [<c02b7d6c>] (kobject_add+0x50/0x98) from [<c03254f8>] (device_add+0xcc/0x5c4) [ 112.614105] [<c03254f8>] (device_add+0xcc/0x5c4) from [<bf000920>] (wiphy_register+0x408/0x67c [cfg80211]) [ 112.624572] [<bf000920>] (wiphy_register+0x408/0x67c [cfg80211]) from [<bf08e55c>] (ieee80211_register_hw+0x3c4/0x810 [mac80211]) [ 112.637084] [<bf08e55c>] (ieee80211_register_hw+0x3c4/0x810 [mac80211]) from [<bf144df0>] (mwl8787_register+0x10/0x38 [mwl8787_sdio]) [ 112.649810] [<bf144df0>] (mwl8787_register+0x10/0x38 [mwl8787_sdio]) from [<bf146fd8>] (mwl8787_fw_cb+0x64/0x84 [mwl8787_sdio]) [ 112.661926] [<bf146fd8>] (mwl8787_fw_cb+0x64/0x84 [mwl8787_sdio]) from [<c0335da8>] (request_firmware_work_func+0x40/0x64) [ 112.673645] [<c0335da8>] (request_firmware_work_func+0x40/0x64) from [<c005f4b0>] (process_one_work+0x1ac/0x4c8) [ 112.684417] [<c005f4b0>] (process_one_work+0x1ac/0x4c8) from [<c005fc0c>] (worker_thread+0x144/0x3ac) [ 112.694152] [<c005fc0c>] (worker_thread+0x144/0x3ac) from [<c0065b6c>] (kthread+0xa4/0xb0) [ 112.702880] [<c0065b6c>] (kthread+0xa4/0xb0) from [<c0013c28>] (ret_from_fork+0x14/0x2c) [ 112.704925] ---[ end trace 92baea39fd3e9318 ]--- Signed-off-by: Bob Copeland <me@bobcopeland.com>
ctwitty
pushed a commit
that referenced
this issue
Mar 13, 2014
Command "tcrypt sec=1 mode=403" give the follwoing error for Polling mode: root@am335x-evm:/# insmod tcrypt.ko sec=1 mode=403 [...] [ 346.982754] test 15 ( 4096 byte blocks, 1024 bytes per update, 4 updates): 4352 opers/sec, 17825792 bytes/sec [ 347.992661] test 16 ( 4096 byte blocks, 4096 bytes per update, 1 updates): 7095 opers/sec, 29061120 bytes/sec [ 349.002667] test 17 ( 8192 byte blocks, 16 bytes per update, 512 updates): [ 349.010882] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 349.020037] pgd = ddeac000 [ 349.022884] [00000000] *pgd=9dcb4831, *pte=00000000, *ppte=00000000 [ 349.029816] Internal error: Oops: 17 [#1] PREEMPT SMP ARM [ 349.035482] Modules linked in: tcrypt(+) [ 349.039617] CPU: 0 PID: 1473 Comm: insmod Not tainted 3.12.4-01566-g6279006-dirty #38 [ 349.047832] task: dda91540 ti: ddcd2000 task.ti: ddcd2000 [ 349.053517] PC is at omap_sham_xmit_dma+0x6c/0x238 [ 349.058544] LR is at omap_sham_xmit_dma+0x38/0x238 [ 349.063570] pc : [<c04eb7cc>] lr : [<c04eb798>] psr: 20000013 [ 349.063570] sp : ddcd3c78 ip : 00000000 fp : 9d8980b8 [ 349.075610] r10: 00000000 r9 : 00000000 r8 : 00000000 [ 349.081090] r7 : 00001000 r6 : dd898000 r5 : 00000040 r4 : ddb10550 [ 349.087935] r3 : 00000004 r2 : 00000010 r1 : 53100080 r0 : 00000000 [ 349.094783] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 349.102268] Control: 10c5387d Table: 9deac019 DAC: 00000015 [ 349.108294] Process insmod (pid: 1473, stack limit = 0xddcd2248) [...] This is because polling_mode is not enabled for ctx without FLAGS_FINUP. For polling mode the bufcnt is made 0 unconditionally. But it should be made 0 only if it is a final update or a total is not zero(This condition is similar to what is done in DMA case). Because of this wrong hashes are produced. Fixing the same. Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Possible memory leak using wireless-testing (commit-id b75ff5e)
root@qemu:~# cat /sys/kernel/debug/kmemleak
unreferenced object 0xffff880015ab84c0 (size 64):
comm "softirq", pid 0, jiffies 4294888798 (age 1166.893s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 01 01 01 00 00 00 01 01 01 00 00 00 01 01 01 ................
backtrace:
[] kmemleak_alloc+0x26/0x50
[] kmem_cache_alloc_trace+0xe7/0x260
[] mesh_add_vendor_ies+0x31/0xf0 [mac80211]
[] ieee80211_mesh_build_beacon+0x44/0x640 [mac80211]
[] mesh_table_alloc+0xb4/0x120 [mac80211]
[] mesh_path_lookup+0x1e/0xb0 [mac80211]
[] ieee80211_mgd_assoc+0x76d/0xb40 [mac80211]
[] ieee80211_mgd_stop+0xc1/0xd0 [mac80211]
[] queues_read+0x3b/0xf0 [mac80211]
[] ieee80211_mgd_probe_ap_send+0x5c/0x240 [mac80211]
[] ieee80211_rx_mgmt_beacon+0x8b5/0x14f0 [mac80211]
[] ieee80211_scan_rx+0x3b/0x2b0 [mac80211]
[] process_one_work+0x1dd/0x6e0
[] worker_thread+0x11b/0x370
[] kthread+0xdb/0xe0
[] ret_from_fork+0x7c/0xb0
unreferenced object 0xffff880015bb3e80 (size 64):
comm "softirq", pid 0, jiffies 4294888798 (age 1166.894s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 01 01 01 00 00 00 01 01 01 00 00 00 01 01 01 ................
backtrace:
[] kmemleak_alloc+0x26/0x50
[] kmem_cache_alloc_trace+0xe7/0x260
[] mesh_add_vendor_ies+0x31/0xf0 [mac80211]
[] ieee80211_mesh_build_beacon+0x44/0x640 [mac80211]
[] mesh_table_alloc+0xb4/0x120 [mac80211]
[] mesh_path_lookup+0x1e/0xb0 [mac80211]
[] ieee80211_mgd_assoc+0x76d/0xb40 [mac80211]
[] ieee80211_mgd_stop+0xc1/0xd0 [mac80211]
[] queues_read+0x3b/0xf0 [mac80211]
[] ieee80211_mgd_probe_ap_send+0x5c/0x240 [mac80211]
[] ieee80211_rx_mgmt_beacon+0x8b5/0x14f0 [mac80211]
[] ieee80211_scan_rx+0x3b/0x2b0 [mac80211]
[] process_one_work+0x1dd/0x6e0
[] worker_thread+0x11b/0x370
[] kthread+0xdb/0xe0
[] ret_from_fork+0x7c/0xb0
root@qemu:~#
The text was updated successfully, but these errors were encountered: