Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1716426
| From | Johannes Weiner <hannes@cmpxchg.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: kernel panic on null pointer on page->mem_cgroup |
| Date | 2017-08-21 15:10 +0200 |
| Message-ID | <ugUCR-4Nm-3@gated-at.bofh.it> (permalink) |
| References | (5 earlier) <uciZc-5aW-23@gated-at.bofh.it> <ucoie-8qy-17@gated-at.bofh.it> <ucp4B-Fu-1@gated-at.bofh.it> <ucE3F-2ye-41@gated-at.bofh.it> <ucUi6-55n-23@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Thu, Aug 10, 2017 at 01:56:05PM +0200, Michal Hocko wrote: > On Wed 09-08-17 14:38:25, Johannes Weiner wrote: > > The issue is that writeback doesn't hold a page reference and the page > > might get freed after PG_writeback is cleared (and the mapping is > > unlocked) in test_clear_page_writeback(). The stat functions looking > > up the page's node or zone are safe, as those attributes are static > > across allocation and free cycles. But page->mem_cgroup is not, and it > > will get cleared if we race with truncation or migration. > > Is there anything that prevents us from holding a reference on a page > under writeback? Hm, I'm hesitant to add redundant life-time management to the page there just for memcg, which is not always configured in. Pinning the memcg instead is slightly more complex, but IMO has the complexity in a preferrable place. Would you agree?
Back to linux.kernel | Previous | Next — Next in thread | Find similar | Unroll thread
Re: kernel panic on null pointer on page->mem_cgroup Johannes Weiner <hannes@cmpxchg.org> - 2017-08-21 15:10 +0200 Re: kernel panic on null pointer on page->mem_cgroup Michal Hocko <mhocko@kernel.org> - 2017-08-21 15:30 +0200
csiph-web