Messages in this thread | | | Subject | Re: [PATCH 2/2] mm: don't hide potentially null memmap pointer in sparse_remove_section | From | "Alastair D'Silva" <> | Date | Tue, 27 Aug 2019 17:00:16 +1000 |
| |
On Tue, 2019-08-27 at 08:24 +0200, Michal Hocko wrote: > On Tue 27-08-19 15:36:55, Alastair D'Silva wrote: > > From: Alastair D'Silva <alastair@d-silva.org> > > > > By adding offset to memmap before passing it in to > > clear_hwpoisoned_pages, > > we hide a theoretically null memmap from the null check inside > > clear_hwpoisoned_pages. > > Isn't that other way around? Calculating the offset struct page > pointer > will actually make the null check effective. Besides that I cannot > really see how pfn_to_page would return NULL. I have to confess that > I > cannot really see how offset could lead to a NULL struct page either > and > I strongly suspect that the NULL check is not really needed. Maybe it > used to be in the past. >
You're probably right, but I didn't feel confident in removing the NULL check.
While the NULL check remains though, I can't see how adding the offset would turn a non-NULL pointer into a NULL unless the pointer is invalid in the first place, and if this is the case, we should have a comment explaining this.
The NULL check was added in commit: 95a4774d055c ("memory-hotplug: update mce_bad_pages when removing the memory") where memmap was originally inited to NULL, and only conditionally given a value.
With this in mind, since that situation is no longer true, I think we could instead drop the NULL check.
-- Alastair D'Silva mob: 0423 762 819 skype: alastair_dsilva Twitter: @EvilDeece blog: http://alastair.d-silva.org
| |