Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1741808
| From | "Yang Shi" <yang.s@alibaba-inc.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH 0/2 v8] oom: capture unreclaimable slab info in oom message |
| Date | 2017-09-28 22:30 +0200 |
| Message-ID | <uuNBv-59j-5@gated-at.bofh.it> (permalink) |
| References | <uusnn-8uO-3@gated-at.bofh.it> <uuyM9-4cw-17@gated-at.bofh.it> <uuL6G-3wn-15@gated-at.bofh.it> <uuN8u-4KX-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On 9/28/17 12:57 PM, Tetsuo Handa wrote: > Yang Shi wrote: >> On 9/27/17 9:36 PM, Tetsuo Handa wrote: >>> On 2017/09/28 6:46, Yang Shi wrote: >>>> Changelog v7 -> v8: >>>> * Adopted Michal’s suggestion to dump unreclaim slab info when unreclaimable slabs amount > total user memory. Not only in oom panic path. >>> >>> Holding slab_mutex inside dump_unreclaimable_slab() was refrained since V2 >>> because there are >>> >>> mutex_lock(&slab_mutex); >>> kmalloc(GFP_KERNEL); >>> mutex_unlock(&slab_mutex); >>> >>> users. If we call dump_unreclaimable_slab() for non OOM panic path, aren't we >>> introducing a risk of crash (i.e. kernel panic) for regular OOM path? >> >> I don't see the difference between regular oom path and oom path other >> than calling panic() at last. >> >> And, the slab dump may be called by panic path too, it is for both >> regular and panic path. > > Calling a function that might cause kerneloops immediately before calling panic() > would be tolerable, for the kernel will panic after all. But calling a function > that might cause kerneloops when there is no plan to call panic() is a bug. I got your point. slab_mutex is used to protect the list of all the slabs, since we are already in oom, there should be not kmem cache destroy happen during the list traverse. And, list_for_each_entry() has been replaced to list_for_each_entry_safe() to make the traverse more robust. Thanks, Yang > >> >> Thanks, >> Yang >> >>> >>> We can try mutex_trylock() from dump_unreclaimable_slab() at best. >>> But it is still remaining unsafe, isn't it? >>> >>
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH 0/2 v8] oom: capture unreclaimable slab info in oom message "Yang Shi" <yang.s@alibaba-inc.com> - 2017-09-27 23:50 +0200
[PATCH 2/2] mm: oom: show unreclaimable slab info when unreclaimable slabs > user memory "Yang Shi" <yang.s@alibaba-inc.com> - 2017-09-27 23:50 +0200
Re: [PATCH 2/2] mm: oom: show unreclaimable slab info when unreclaimable slabs > user memory Christopher Lameter <cl@linux.com> - 2017-10-01 08:20 +0200
Re: [PATCH 0/2 v8] oom: capture unreclaimable slab info in oom message Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2017-09-28 06:40 +0200
Re: [PATCH 0/2 v8] oom: capture unreclaimable slab info in oom message "Yang Shi" <yang.s@alibaba-inc.com> - 2017-09-28 19:50 +0200
Re: [PATCH 0/2 v8] oom: capture unreclaimable slab info in oom message Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2017-09-28 22:00 +0200
Re: [PATCH 0/2 v8] oom: capture unreclaimable slab info in oom message "Yang Shi" <yang.s@alibaba-inc.com> - 2017-09-28 22:30 +0200
Re: [PATCH 0/2 v8] oom: capture unreclaimable slab info in oom message Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2017-09-28 22:50 +0200
Re: [PATCH 0/2 v8] oom: capture unreclaimable slab info in oom message "Yang Shi" <yang.s@alibaba-inc.com> - 2017-09-30 00:20 +0200
Re: [PATCH 0/2 v8] oom: capture unreclaimable slab info in oom message Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> - 2017-09-30 13:10 +0200
Re: [PATCH 0/2 v8] oom: capture unreclaimable slab info in oom message "Yang Shi" <yang.s@alibaba-inc.com> - 2017-10-02 22:50 +0200
Re: [PATCH 0/2 v8] oom: capture unreclaimable slab info in oom message Michal Hocko <mhocko@kernel.org> - 2017-10-02 13:30 +0200
Re: [PATCH 0/2 v8] oom: capture unreclaimable slab info in oom message "Yang Shi" <yang.s@alibaba-inc.com> - 2017-10-02 22:50 +0200
csiph-web